romych/ESPKit
1
0
Fork 0
mirror of https://github.com/romychs/ESPKit.git synced 2025-04-18 01:52:41 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

WFTP First impl

Browse Source
This commit is contained in:
boykovra 2024-08-02 12:09:18 +03:00
parent 2d74d03448
commit 69deb4907a
20 changed files with 3338 additions and 216 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
sources/DSS/.vscode/launch.json vendored
View File

@ -155,7 +155,7 @@
"codeCoverageEnabled": true
},
"startAutomatically": false,
"commandsAfterLaunch": [],
"commandsAfterLaunch": ["-rmv"],
"rootFolder": "${workspaceFolder}",
"topOfStack": "STACK_TOP",
"loadObjs": [
@ -167,6 +167,90 @@
"execAddress": "0x8100",
"smallValuesMaximum": 513,
"tmpDir": ".tmp"
},
{
"type": "dezog",
"request": "launch",
"name": "WTFTP Internal Simulator",
"remoteType": "zsim",
"zsim": {
"visualMemory": true,
"memoryModel": "CUSTOM",
"customMemory": {
"slots": [
{
"name": "PAGE0",
"range": ["0x0000","0x3FFF"],
"banks": [{"index": [0, 255]}],
"initialBank": 0
},
{
"name": "PAGE1",
"range": ["0x4000","0x7FFF"],
"banks": [{"index": [0, 255]}],
"initialBank": 1
},
{
"name": "PAGE2",
"range": ["0x8000","0xBFFF"],
"banks": [{"index": [0, 255]}],
"initialBank": 2
},
{
"name": "PAGE3",
"range": ["0xC000","0xFFFF"],
"banks": [{"index": [0, 255]}],
"initialBank": 3
}
],
"ioMmu": [
"if (portAddress == 0x82) {",
" bank = portValue;",
" PAGE0 = bank;",
"}",
"if (portAddress == 0xA2) {",
" bank = portValue;",
" PAGE1 = bank;",
"}",
"if (portAddress == 0xC2) {",
" bank = portValue;",
" PAGE2 = bank;",
"}",
"if (portAddress == 0xE2) {",
" bank = portValue;",
" PAGE3 = bank;",
"}"
]
},
"customCode": {
"debug": false,
"jsPath": "sim/ports.js"
},
},
"sjasmplus": [
{
"path": "wtftp.sld"
}
],
"history": {
"reverseDebugInstructionCount": 1000000,
"spotCount": 10,
"codeCoverageEnabled": true
},
"startAutomatically": false,
"commandsAfterLaunch": ["-rmv"],
"rootFolder": "${workspaceFolder}",
"topOfStack": "STACK_TOP",
"loadObjs": [
{
"path": "wtftp.exe",
"start": "0x0000"
}
],
"execAddress": "0x8100",
"smallValuesMaximum": 513,
"tmpDir": ".tmp"
}
]

59
sources/DSS/.vscode/tasks.json vendored
View File

@ -53,7 +53,7 @@
},
"group": {
"kind": "build",
"isDefault": true
"isDefault": false
}
},
@ -85,6 +85,63 @@
}
},
{
"label": "make ESPLIB (sjasmplus)",
"type": "shell",
"command": "sjasmplus",
"args": [
"--sld=esplib.sld",
"--sym=esplib.labels",
"--raw=esplib.exe",
"--fullpath",
"esplib.asm"
],
"problemMatcher": {
"owner": "sjasmplus",
"fileLocation": "autoDetect",
"pattern": {
"regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*)$",
"file": 1,
"line": 2,
"severity": 3,
"message": 4
}
},
"group": {
"kind": "build",
"isDefault": false
}
},
{
"label": "make WTFTP (sjasmplus)",
"type": "shell",
"command": "sjasmplus",
"args": [
"--sld=wtftp.sld",
"--sym=wtftp.labels",
"--raw=wtftp.exe",
"--fullpath",
"wtftp.asm"
],
"problemMatcher": {
"owner": "sjasmplus",
"fileLocation": "autoDetect",
"pattern": {
"regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*)$",
"file": 1,
"line": 2,
"severity": 3,
"message": 4
}
},
"group": {
"kind": "build",
"isDefault": true
}
},
{
"label": "start mame",
"type": "shell",

22
sources/DSS/dss.asm
View File

@ -169,7 +169,7 @@ _CLOSE_FILE
JP NORM_EXIT
CUR_F_PTR
DW ZIP_FILE
DW IN_FILE
REMAINS_IN_ZIP
DW 0
@ -192,7 +192,7 @@ _READ_FILE
PUSH HL
LD HL, (CUR_F_PTR) ; HL -> IN ZIP_FILE
LD DE, ZIP_FILE_END
LD DE, IN_FILE_END
EX HL, DE
SUB HL, DE ; HL = remain bytes
LD (REMAINS_IN_ZIP), HL
@ -225,7 +225,7 @@ _WRITE_FILE
PUSH DE
POP BC
LD DE,UNZIP_FILE
LD DE,OUT_FILE
PUSH BC
LDIR
@ -279,7 +279,7 @@ _FIND_FIRST
LD HL, 33 ; offset of file name
ADD HL, DE
EX HL, DE
LD HL, ZIP_FILE_NAME
LD HL, IN_FILE_NAME
LD BC,9
LDIR
POP DE
@ -360,13 +360,15 @@ _EXIT
HALT
JP _EXIT
ZIP_FILE_NAME
DB "file.zip",0
ZIP_FILE
CMD_LINE_TFTP_D
DB " tftp://tftp.server.ru:1024/file_in.asm c:\\tmp\\file_out.asm"Z
IN_FILE
DS 1024,0
ZIP_FILE_END
UNZIP_FILE
IN_FILE_END
IN_FILE_NAME
DB "infile.txt"
OUT_FILE
DS 1024,0
ALIGN 16384, 0

12
sources/DSS/dss.inc
View File

@ -4,6 +4,9 @@
; https://github.com/romychs
; ======================================================
IFNDEF _DSS_INC
DEFINE _DSS_INC
; DSS RST Entry
DSS EQU 0x10
@ -55,3 +58,12 @@ KB_R_SHIFT EQU 0x40
KB_L_SHIFT EQU 0x80
; File attributes
FA_READONLY EQU 0x01
FA_HIDDEN EQU 0x02
FA_SYSTEM EQU 0x04
FA_LABEL EQU 0x08
FA_DIRECTORY EQU 0x10
FA_ARCHIVE EQU 0x20
ENDIF

230
sources/DSS/esplib.asm
View File

@ -5,6 +5,10 @@
; License: BSD 3-Clause
; ======================================================
INCLUDE "isa.asm"
INCLUDE "util.asm"
;ISA_BASE_A EQU 0xC000 ; Базовый адрес портов ISA в памяти
PORT_UART EQU 0x03E8 ; Базовый номер порта COM3
PORT_UART_A EQU ISA_BASE_A + PORT_UART ; Порты чипа UART в памяти
@ -101,6 +105,7 @@ _AFR EQU 2
; Find TL550C in ISA slot
; Out: CF=1 - Not found, CF=0 - ISA.ISA_SLOT found in slot
; ------------------------------------------------------
;IFUSED UART_FIND
UART_FIND
PUSH HL
XOR A
@ -113,7 +118,6 @@ UART_FIND
UF_T_FND
POP HL
RET
; Test slot, A - ISA Slot no. 0 or 1
UT_T_SLOT
; check IER hi bits, will be 0
@ -137,12 +141,12 @@ CHK_SCR
CALL UART_READ
CP D
RET
;ENDIF
; ------------------------------------------------------
; Init UART device TL16C550
; ------------------------------------------------------
;IFUSED UART_INIT
UART_INIT
PUSH AF, IX
@ -166,41 +170,47 @@ UART_INIT
POP IX,AF
RET
;ENDIF
; ------------------------------------------------------
; Read TL16C550 register
; Inp: HL - register
; Out: A - value from register
; ------------------------------------------------------
;IFUSED UART_READ
UART_READ
CALL ISA.ISA_OPEN
LD A, (HL)
CALL ISA.ISA_CLOSE
RET
;ENDIF
; ------------------------------------------------------
; Write TL16C550 register
; Inp: HL - register, E - value
; ------------------------------------------------------
;IFUSED UART_WRITE
UART_WRITE
CALL ISA.ISA_OPEN
LD (HL), E
CALL ISA.ISA_CLOSE
RET
;ENDIF
; ------------------------------------------------------
; Wait for transmitter ready
; Out: CF=1 - tr not ready, CF=0 ready
; ------------------------------------------------------
;IFUSED UART_WAIT_TR
UART_WAIT_TR
CALL ISA.ISA_OPEN
CALL UART_WAIT_TR_INT
CALL ISA.ISA_CLOSE
RET
;ENDIF
;
; Wait, without open/close ISA
;
;IFUSED UART_WAIT_TR_INT
UART_WAIT_TR_INT
PUSH BC, HL, DE
LD D,A
@ -210,7 +220,7 @@ WAIT_TR_BZY
LD A,(HL)
AND A, LSR_THRE
JR NZ,WAIT_TR_RDY
CALL UTIL.DELAY_100uS ; ~11 bit tx delay
CALL @UTIL.DELAY_100uS ; ~11 bit tx delay
DEC BC
LD A, C
OR B
@ -220,12 +230,14 @@ WAIT_TR_RDY
LD A,D
POP DE, HL, BC
RET
;ENDIF
; ------------------------------------------------------
; Transmit byte
; Inp: E - byte
; Out: CF=1 - Not ready
; ------------------------------------------------------
;IFUSED UART_TX_BYTE
UART_TX_BYTE
PUSH DE
CALL UART_WAIT_TR
@ -236,12 +248,13 @@ UART_TX_BYTE
UTB_NOT_R
POP DE
RET
;ENDIF
; ------------------------------------------------------
; Transmit buffer
; Inp: HL -> buffer, BC - size
; Out: CF=0 - Ok, CF=1 - Timeout
; ------------------------------------------------------
;IFUSED UART_TX_BUFFER
UART_TX_BUFFER
PUSH BC,DE,HL
LD DE, REG_THR
@ -267,12 +280,14 @@ UTX_TXNR
CALL ISA.ISA_CLOSE
POP HL,DE,BC
RET
;ENDIF
; ------------------------------------------------------
; Transmit zero ended string
; Inp: HL -> buffer
; Out: CF=0 - Ok, CF=1 - Timeout
; ------------------------------------------------------
;IFUSED UART_TX_STRING
UART_TX_STRING
PUSH DE,HL
LD DE, REG_THR
@ -296,13 +311,12 @@ UTXS_TXNR
CALL ISA.ISA_CLOSE
POP HL,DE
RET
;ENDIF
; ------------------------------------------------------
; Empty receiver FIFO buffer
; ------------------------------------------------------
;IFUSED UART_EMPTY_RS
UART_EMPTY_RS
PUSH DE, HL
LD E, FCR_TR8 | FCR_RESET_RX | FCR_FIFO
@ -310,6 +324,7 @@ UART_EMPTY_RS
CALL UART_WRITE
POP HL, DE
RET
;ENDIF
; ------------------------------------------------------
; Wait byte in receiver fifo
@ -333,7 +348,7 @@ UVR_NEXT
OR C
JR NZ,UVR_NEXT
UVR_TO
IF TRACE
IFDEF TRACE
PUSH AF,BC,DE,HL
PRINTLN MSG_RCV_EMPTY
POP HL,DE,BC,AF
@ -342,10 +357,11 @@ UVR_TO
UVR_OK
POP HL,BC
RET
; ------------------------------------------------------
; Reset ESP module
; ------------------------------------------------------
;IFUSED ESP_RESET
ESP_RESET
PUSH AF,HL
@ -365,17 +381,7 @@ ESP_RESET
POP HL,AF
RET
; Receive block size
BSIZE DW 0
; Received message for OK result
MSG_OK DB "OK", 0
; Received message for Error
MSG_ERROR DB "ERROR", 0
; Received message for Failure
MSG_FAIL DB "FAIL", 0
;ENDIF
; ------------------------------------------------------
; UART TX Command
@ -384,104 +390,122 @@ MSG_FAIL DB "FAIL", 0
; BC - wait ms
; Out: CF=1 if Error
; ------------------------------------------------------
;IFUSED UART_TX_CMD
UART_TX_CMD
PUSH BC, DE, HL
PUSH BC, DE, HL
LD A, low RS_BUFF_SIZE
LD (BSIZE), A
LD A, high RS_BUFF_SIZE
LD (BSIZE+1), A
LD A, low RS_BUFF_SIZE
LD (BSIZE), A
LD A, high RS_BUFF_SIZE
LD (BSIZE+1), A
;LD (RESBUF),DE
XOR A
LD (DE), A
;LD (RESBUF),DE
XOR A
LD (DE), A
LD (WAIT_MS), BC
CALL UART_EMPTY_RS
LD (WAIT_MS), BC
CALL UART_EMPTY_RS
; HL - Buffer, BC - Size
;CALL UTIL.STRLEN
CALL UART_TX_STRING
JR NC, UTC_STRT_RX
; error, transmit timeout
LD A, RES_TX_TIMEOUT
JR UTC_RET
; HL - Buffer, BC - Size
;CALL UTIL.STRLEN
CALL UART_TX_STRING
JR NC, UTC_STRT_RX
; error, transmit timeout
LD A, RES_TX_TIMEOUT
JR UTC_RET
UTC_STRT_RX
; no transmit timeout, receive response
; IX - pointer to begin of current line
LD IXH, D
LD IXL, E
LD BC,(BSIZE)
; no transmit timeout, receive response
; IX - pointer to begin of current line
LD IXH, D
LD IXL, E
LD BC,(BSIZE)
UTC_RCV_NXT
; wait receiver ready
;LD BC,(WAIT_MS)
CALL UART_WAIT_RS1
JR NC, UTC_NO_RT
; error, read timeout
LD A, RES_RS_TIMEOUT
JR UTC_RET
; no receive timeout
; wait receiver ready
;LD BC,(WAIT_MS)
CALL UART_WAIT_RS1
JR NC, UTC_NO_RT
; error, read timeout
LD A, RES_RS_TIMEOUT
JR UTC_RET
; no receive timeout
UTC_NO_RT
; read symbol from tty
LD HL, REG_RBR
CALL UART_READ
CP CR
JP Z, UTC_RCV_NXT ; Skip CR
CP LF
JR Z, UTC_END ; LF - last symbol in responce
LD (DE),A
INC DE
DEC BC
LD A, B
OR C
JR NZ, UTC_RCV_NXT
; read symbol from tty
LD HL, REG_RBR
CALL UART_READ
CP CR
JP Z, UTC_RCV_NXT ; Skip CR
CP LF
JR Z, UTC_END ; LF - last symbol in responce
LD (DE),A
INC DE
DEC BC
LD A, B
OR C
JR NZ, UTC_RCV_NXT
UTC_END
XOR A
LD (DE),A ; temporary mark end of string
PUSH DE ; store DE
POP IY
PUSH IX
POP DE ; DE - ptr to begin pf current line
XOR A
LD (DE),A ; temporary mark end of string
PUSH DE ; store DE
POP IY
PUSH IX
POP DE ; DE - ptr to begin pf current line
; It is 'OK<LF>'?
LD HL, MSG_OK
CALL UTIL.STRCMP
JR NC, UTC_RET
; It is 'ERROR<LF>'?
LD HL,MSG_ERROR
CALL UTIL.STRCMP
JR C, UTC_CP_FAIL
LD A, RES_ERROR
; It is 'FAIL<LF>'?
JR UTC_RET
; It is 'OK<LF>'?
LD HL, MSG_OK
CALL UTIL.STRCMP
JR NC, UTC_RET
; It is 'ERROR<LF>'?
LD HL,MSG_ERROR
CALL UTIL.STRCMP
JR C, UTC_CP_FAIL
LD A, RES_ERROR
; It is 'FAIL<LF>'?
JR UTC_RET
UTC_CP_FAIL
LD HL,MSG_FAIL
CALL UTIL.STRCMP
JR C, UTC_NOMSG
LD A, RES_FAIL
JR UTC_RET
LD HL,MSG_FAIL
CALL @UTIL.STRCMP
JR C, UTC_NOMSG
LD A, RES_FAIL
JR UTC_RET
UTC_NOMSG
; no resp message, continue receive
PUSH IY
POP DE
LD A, LF
LD (DE),A ; change 0 - EOL to LF
INC DE
LD IXH,D ; store new start line ptr
LD IXL,E
JR UTC_RCV_NXT
; no resp message, continue receive
PUSH IY
POP DE
LD A, LF
LD (DE),A ; change 0 - EOL to LF
INC DE
LD IXH,D ; store new start line ptr
LD IXL,E
JR UTC_RCV_NXT
UTC_RET
POP HL, DE, BC
RET
POP HL, DE, BC
RET
;ENDIF
IF TRACE
IFDEF TRACE
MSG_RCV_EMPTY
DB "Receiver is empty!",0
ENDIF
; ------------------------------------------------------
; Data definition
; ------------------------------------------------------
; Receive block size
BSIZE DW 0
; Received message for OK result
MSG_OK DB "OK", 0
; Received message for Error
MSG_ERROR DB "ERROR", 0
; Received message for Failure
MSG_FAIL DB "FAIL", 0
IFUSED RS_BUFF
; Buffer to receive response from ESP
RS_BUFF DS RS_BUFF_SIZE, 0
ENDIF
ENDMODULE

31
sources/DSS/isa-test.asm
View File

@ -57,7 +57,8 @@ START
JP MAIN_LOOP
ENDIF
CALL @WCOMMON.INIT_VMODE
PRINTLN MSG_START
@ -79,12 +80,28 @@ START
; INC D
CALL ISA.ISA_OPEN
LD HL, PORT_UART_A
LD HL, REG_SCR
LD D,0x55
L_AGAIN
.1000 LD (HL), D
.1000 LD D,(HL)
JP L_AGAIN
LD BC, PORT_ISA
LD A, ISA_AEN ; AEN=1 (for sync LA by front)
OUT (C), A
;
LD (HL), D
LD D,(HL)
LD D,0xAA
LD (HL), D
LD D,(HL)
LD BC, PORT_ISA
LD A, 0 ; AEN=0
OUT (C), A
CALL ISA.ISA_CLOSE
; --------- RESET & AEN --------------
; LD BC, PORT_ISA
@ -108,7 +125,7 @@ MAIN_LOOP
OK_EXIT
LD B,0
JP WCOMMON.EXIT
JP @WCOMMON.EXIT
; ------------------------------------------------------

14
sources/DSS/isa.asm
View File

@ -5,6 +5,12 @@
; License: BSD 3-Clause
; ======================================================
IFNDEF _ISA_ASM
DEFINE _ISA_ASM
INCLUDE "sprinter.inc"
INCLUDE "util.asm"
PORT_ISA EQU 0x9FBD
PORT_SYSTEM EQU 0x1FFD
@ -29,11 +35,11 @@ ISA_RESET
LD BC, PORT_ISA
LD A,ISA_RST | ISA_AEN ; RESET=1 AEN=1
OUT (C), A
CALL UTIL.DELAY_1MS
CALL @UTIL.DELAY_1MS
XOR A
OUT (C), A ; RESET=0 AEN=0
LD HL,100
CALL UTIL.DELAY
CALL @UTIL.DELAY
RET
; ------------------------------------------------------
@ -77,4 +83,6 @@ ISA_CLOSE
; To save memory page 3
SAVE_MMU3 DB 0
ENDMODULE
ENDMODULE
ENDIF

10
sources/DSS/macro.inc
View File

@ -5,10 +5,13 @@
; License: BSD 3-Clause
; ======================================================
IFNDEF _MACRO
DEFINE _MACRO
; Transmit data|command via UART and check response
MACRO SEND_CMD data
LD HL, data
CALL WIFI.UART_TX_CMD
CALL @WIFI.UART_TX_CMD
CALL CHECK_ERROR
ENDM
@ -46,4 +49,7 @@
LD C,func
ENDIF
RST DSS
ENDM
ENDM
ENDIF

14
sources/DSS/rfc/README.md Normal file
View File

@ -0,0 +1,14 @@
# TFTP Specifications
## Current RFC
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2090 - TFTP Multicast Option
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC7440 - TFTP Windowsize Option
## Obsolete RFC
RFC1782 - TFTP Option Extension
RFC1783 - TFTP Blocksize Option
RFC1784 - TFTP Timeout Interval and Transfer Size Options

619
sources/DSS/rfc/rfc1350.txt Normal file
View File

@ -0,0 +1,619 @@
Network Working Group K. Sollins
Request For Comments: 1350 MIT
STD: 33 July 1992
Obsoletes: RFC 783
THE TFTP PROTOCOL (REVISION 2)
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Summary
TFTP is a very simple protocol used to transfer files. It is from
this that its name comes, Trivial File Transfer Protocol or TFTP.
Each nonterminal packet is acknowledged separately. This document
describes the protocol and its types of packets. The document also
explains the reasons behind some of the design decisions.
Acknowlegements
The protocol was originally designed by Noel Chiappa, and was
redesigned by him, Bob Baldwin and Dave Clark, with comments from
Steve Szymanski. The current revision of the document includes
modifications stemming from discussions with and suggestions from
Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
Yellick, and the author. The acknowledgement and retransmission
scheme was inspired by TCP, and the error mechanism was suggested by
PARC's EFTP abort message.
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
bug [4] and other minor document problems was done by Noel Chiappa.
This research was supported by the Advanced Research Projects Agency
of the Department of Defense and was monitored by the Office of Naval
Research under contract number N00014-75-C-0661.
1. Purpose
TFTP is a simple protocol to transfer files, and therefore was named
the Trivial File Transfer Protocol or TFTP. It has been implemented
on top of the Internet User Datagram protocol (UDP or Datagram) [2]
Sollins [Page 1]
RFC 1350 TFTP Revision 2 July 1992
so it may be used to move files between machines on different
networks implementing UDP. (This should not exclude the possibility
of implementing TFTP on top of other datagram protocols.) It is
designed to be small and easy to implement. Therefore, it lacks most
of the features of a regular FTP. The only thing it can do is read
and write files (or mail) from/to a remote server. It cannot list
directories, and currently has no provisions for user authentication.
In common with other Internet protocols, it passes 8 bit bytes of
data.
Three modes of transfer are currently supported: netascii (This is
ascii as defined in "USA Standard Code for Information Interchange"
[1] with the modifications specified in "Telnet Protocol
Specification" [3].) Note that it is 8 bit ascii. The term
"netascii" will be used throughout this document to mean this
particular version of ascii.); octet (This replaces the "binary" mode
of previous versions of this document.) raw 8 bit bytes; mail,
netascii characters sent to a user rather than a file. (The mail
mode is obsolete and should not be implemented or used.) Additional
modes can be defined by pairs of cooperating hosts.
Reference [4] (section 4.2) should be consulted for further valuable
directives and suggestions on TFTP.
2. Overview of the Protocol
Any transfer begins with a request to read or write a file, which
also serves to request a connection. If the server grants the
request, the connection is opened and the file is sent in fixed
length blocks of 512 bytes. Each data packet contains one block of
data, and must be acknowledged by an acknowledgment packet before the
next packet can be sent. A data packet of less than 512 bytes
signals termination of a transfer. If a packet gets lost in the
network, the intended recipient will timeout and may retransmit his
last packet (which may be data or an acknowledgment), thus causing
the sender of the lost packet to retransmit that lost packet. The
sender has to keep just one packet on hand for retransmission, since
the lock step acknowledgment guarantees that all older packets have
been received. Notice that both machines involved in a transfer are
considered senders and receivers. One sends data and receives
acknowledgments, the other sends acknowledgments and receives data.
Most errors cause termination of the connection. An error is
signalled by sending an error packet. This packet is not
acknowledged, and not retransmitted (i.e., a TFTP server or user may
terminate after sending an error message), so the other end of the
connection may not get it. Therefore timeouts are used to detect
such a termination when the error packet has been lost. Errors are
Sollins [Page 2]
RFC 1350 TFTP Revision 2 July 1992
caused by three types of events: not being able to satisfy the
request (e.g., file not found, access violation, or no such user),
receiving a packet which cannot be explained by a delay or
duplication in the network (e.g., an incorrectly formed packet), and
losing access to a necessary resource (e.g., disk full or access
denied during a transfer).
TFTP recognizes only one error condition that does not cause
termination, the source port of a received packet being incorrect.
In this case, an error packet is sent to the originating host.
This protocol is very restrictive, in order to simplify
implementation. For example, the fixed length blocks make allocation
straight forward, and the lock step acknowledgement provides flow
control and eliminates the need to reorder incoming data packets.
3. Relation to other Protocols
As mentioned TFTP is designed to be implemented on top of the
Datagram protocol (UDP). Since Datagram is implemented on the
Internet protocol, packets will have an Internet header, a Datagram
header, and a TFTP header. Additionally, the packets may have a
header (LNI, ARPA header, etc.) to allow them through the local
transport medium. As shown in Figure 3-1, the order of the contents
of a packet will be: local medium header, if used, Internet header,
Datagram header, TFTP header, followed by the remainder of the TFTP
packet. (This may or may not be data depending on the type of packet
as specified in the TFTP header.) TFTP does not specify any of the
values in the Internet header. On the other hand, the source and
destination port fields of the Datagram header (its format is given
in the appendix) are used by TFTP and the length field reflects the
size of the TFTP packet. The transfer identifiers (TID's) used by
TFTP are passed to the Datagram layer to be used as ports; therefore
they must be between 0 and 65,535. The initialization of TID's is
discussed in the section on initial connection protocol.
The TFTP header consists of a 2 byte opcode field which indicates
the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the
formats of the various types of packets are discussed further in the
section on TFTP packets.
Sollins [Page 3]
RFC 1350 TFTP Revision 2 July 1992
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
Figure 3-1: Order of Headers
4. Initial Connection Protocol
A transfer is established by sending a request (WRQ to write onto a
foreign file system, or RRQ to read from it), and receiving a
positive reply, an acknowledgment packet for write, or the first data
packet for read. In general an acknowledgment packet will contain
the block number of the data packet being acknowledged. Each data
packet has associated with it a block number; block numbers are
consecutive and begin with one. Since the positive response to a
write request is an acknowledgment packet, in this special case the
block number will be zero. (Normally, since an acknowledgment packet
is acknowledging a data packet, the acknowledgment packet will
contain the block number of the data packet being acknowledged.) If
the reply is an error packet, then the request has been denied.
In order to create a connection, each end of the connection chooses a
TID for itself, to be used for the duration of that connection. The
TID's chosen for a connection should be randomly chosen, so that the
probability that the same number is chosen twice in immediate
succession is very low. Every packet has associated with it the two
TID's of the ends of the connection, the source TID and the
destination TID. These TID's are handed to the supporting UDP (or
other datagram protocol) as the source and destination ports. A
requesting host chooses its source TID as described above, and sends
its initial request to the known TID 69 decimal (105 octal) on the
serving host. The response to the request, under normal operation,
uses a TID chosen by the server as its source TID and the TID chosen
for the previous message by the requestor as its destination TID.
The two chosen TID's are then used for the remainder of the transfer.
As an example, the following shows the steps used to establish a
connection to write a file. Note that WRQ, ACK, and DATA are the
names of the write request, acknowledgment, and data types of packets
respectively. The appendix contains a similar example for reading a
file.
Sollins [Page 4]
RFC 1350 TFTP Revision 2 July 1992
1. Host A sends a "WRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "ACK" (with block number= 0) to host A with
source= B's TID, destination= A's TID.
At this point the connection has been established and the first data
packet can be sent by Host A with a sequence number of 1. In the
next step, and in all succeeding steps, the hosts should make sure
that the source TID matches the value that was agreed on in steps 1
and 2. If a source TID does not match, the packet should be
discarded as erroneously sent from somewhere else. An error packet
should be sent to the source of the incorrect packet, while not
disturbing the transfer. This can be done only if the TFTP in fact
receives a packet with an incorrect TID. If the supporting protocols
do not allow it, this particular error condition will not arise.
The following example demonstrates a correct operation of the
protocol in which the above situation can occur. Host A sends a
request to host B. Somewhere in the network, the request packet is
duplicated, and as a result two acknowledgments are returned to host
A, with different TID's chosen on host B in response to the two
requests. When the first response arrives, host A continues the
connection. When the second response to the request arrives, it
should be rejected, but there is no reason to terminate the first
connection. Therefore, if different TID's are chosen for the two
connections on host B and host A checks the source TID's of the
messages it receives, the first connection can be maintained while
the second is rejected by returning an error packet.
5. TFTP Packets
TFTP supports five types of packets, all of which have been mentioned
above:
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)
The TFTP header of a packet contains the opcode associated with
that packet.
Sollins [Page 5]
RFC 1350 TFTP Revision 2 July 1992
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
Figure 5-1: RRQ/WRQ packet
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
shown in Figure 5-1. The file name is a sequence of bytes in
netascii terminated by a zero byte. The mode field contains the
string "netascii", "octet", or "mail" (or any combination of upper
and lower case, such as "NETASCII", NetAscii", etc.) in netascii
indicating the three modes defined in the protocol. A host which
receives netascii mode data must translate the data to its own
format. Octet mode is used to transfer a file that is in the 8-bit
format of the machine from which the file is being transferred. It
is assumed that each type of machine has a single 8-bit format that
is more common, and that that format is chosen. For example, on a
DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
four bits of breakage. If a host receives a octet file and then
returns it, the returned file must be identical to the original.
Mail mode uses the name of a mail recipient in place of a file and
must begin with a WRQ. Otherwise it is identical to netascii mode.
The mail recipient string should be of the form "username" or
"username@hostname". If the second form is used, it allows the
option of mail forwarding by a relay computer.
The discussion above assumes that both the sender and recipient are
operating in the same mode, but there is no reason that this has to
be the case. For example, one might build a storage server. There
is no reason that such a machine needs to translate netascii into its
own form of text. Rather, the sender might send files in netascii,
but the storage server might simply store them without translation in
8-bit format. Another such situation is a problem that currently
exists on DEC-20 systems. Neither netascii nor octet accesses all
the bits in a word. One might create a special mode for such a
machine which read all the bits in a word, but in which the receiver
stored the information in 8-bit format. When such a file is
retrieved from the storage site, it must be restored to its original
form to be useful, so the reverse mode must also be implemented. The
user site will have to remember some information to achieve this. In
both of these examples, the request packets would specify octet mode
to the foreign host, but the local host would be in some other mode.
No such machine or application specific modes have been specified in
TFTP, but one would be compatible with this specification.
It is also possible to define other modes for cooperating pairs of
Sollins [Page 6]
RFC 1350 TFTP Revision 2 July 1992
hosts, although this must be done with care. There is no requirement
that any other hosts implement these. There is no central authority
that will define these modes or assign them names.
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
Figure 5-2: DATA packet
Data is actually transferred in DATA packets depicted in Figure 5-2.
DATA packets (opcode = 3) have a block number and data field. The
block numbers on data packets begin with one and increase by one for
each new block of data. This restriction allows the program to use a
single number to discriminate between new packets and duplicates.
The data field is from zero to 512 bytes long. If it is 512 bytes
long, the block is not the last block of data; if it is from zero to
511 bytes long, it signals the end of the transfer. (See the section
on Normal Termination for details.)
All packets other than duplicate ACK's and those used for
termination are acknowledged unless a timeout occurs [4]. Sending a
DATA packet is an acknowledgment for the first ACK packet of the
previous DATA packet. The WRQ and DATA packets are acknowledged by
ACK or ERROR packets, while RRQ
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
Figure 5-3: ACK packet
and ACK packets are acknowledged by DATA or ERROR packets. Figure
5-3 depicts an ACK packet; the opcode is 4. The block number in
an ACK echoes the block number of the DATA packet being
acknowledged. A WRQ is acknowledged with an ACK packet having a
block number of zero.
Sollins [Page 7]
RFC 1350 TFTP Revision 2 July 1992
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
Figure 5-4: ERROR packet
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
ERROR packet can be the acknowledgment of any other type of packet.
The error code is an integer indicating the nature of the error. A
table of values and meanings is given in the appendix. (Note that
several error codes have been added to this version of this
document.) The error message is intended for human consumption, and
should be in netascii. Like all other strings, it is terminated with
a zero byte.
6. Normal Termination
The end of a transfer is marked by a DATA packet that contains
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
packet is acknowledged by an ACK packet like all other DATA packets.
The host acknowledging the final DATA packet may terminate its side
of the connection on sending the final ACK. On the other hand,
dallying is encouraged. This means that the host sending the final
ACK will wait for a while before terminating in order to retransmit
the final ACK if it has been lost. The acknowledger will know that
the ACK has been lost if it receives the final DATA packet again.
The host sending the last DATA must retransmit it until the packet is
acknowledged or the sending host times out. If the response is an
ACK, the transmission was completed successfully. If the sender of
the data times out and is not prepared to retransmit any more, the
transfer may still have been completed successfully, after which the
acknowledger or network may have experienced a problem. It is also
possible in this case that the transfer was unsuccessful. In any
case, the connection has been closed.
7. Premature Termination
If a request can not be granted, or some error occurs during the
transfer, then an ERROR packet (opcode 5) is sent. This is only a
courtesy since it will not be retransmitted or acknowledged, so it
may never be received. Timeouts must also be used to detect errors.
Sollins [Page 8]
RFC 1350 TFTP Revision 2 July 1992
I. Appendix
Order of Headers
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------
TFTP Formats
Type Op # Format without header
2 bytes string 1 byte string 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n bytes
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2 bytes
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string 1 byte
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------
Initial Connection Protocol for reading a file
1. Host A sends a "RRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "DATA" (with block number= 1) to host A with
source= B's TID, destination= A's TID.
Sollins [Page 9]
RFC 1350 TFTP Revision 2 July 1992
Error Codes
Value Meaning
0 Not defined, see error message (if any).
1 File not found.
2 Access violation.
3 Disk full or allocation exceeded.
4 Illegal TFTP operation.
5 Unknown transfer ID.
6 File already exists.
7 No such user.
Internet User Datagram Header [2]
(This has been included only for convenience. TFTP need not be
implemented on top of the Internet User Datagram Protocol.)
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values of Fields
Source Port Picked by originator of packet.
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Length Number of bytes in UDP packet, including UDP header.
Checksum Reference 2 describes rules for computing checksum.
(The implementor of this should be sure that the
correct algorithm is used here.)
Field contains zero if unused.
Note: TFTP passes transfer identifiers (TID's) to the Internet User
Datagram protocol to be used as the source and destination ports.
Sollins [Page 10]
RFC 1350 TFTP Revision 2 July 1992
References
[1] USA Standard Code for Information Interchange, USASI X3.4-1968.
[2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[3] Postel, J., "Telnet Protocol Specification," RFC 764,
USC/Information Sciences Institute, June, 1980.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, USC/Information Sciences
Institute, October 1989.
Security Considerations
Since TFTP includes no login or access control mechanisms, care must
be taken in the rights granted to a TFTP server process so as not to
violate the security of the server hosts file system. TFTP is often
installed with controls such that only files that have public read
access are available via TFTP and writing files via TFTP is
disallowed.
Author's Address
Karen R. Sollins
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
Phone: (617) 253-6006
EMail: SOLLINS@LCS.MIT.EDU
Sollins [Page 11]

339
sources/DSS/rfc/rfc2090.txt Normal file
View File

@ -0,0 +1,339 @@
Network Working Group A. Emberson
Request for Comments: 2090 Lanworks Technologies Inc.
Category: Experimental February 1997
TFTP Multicast Option
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host.
This document describes a new TFTP option. This new option will allow
the multiple clients to receive the same file concurrently through
the use of Multicast packets. The TFTP Option Extension mechanism is
described in [2].
Often when similar computers are booting remotely they will each
download the same image file. By adding multicast into the TFTP
option set, two or more computers can download a file
concurrently, thus increasing network efficiency.
This document assumes that the reader is familiar with the
terminology and notation of both [1] and [2].
Multicast Option Specification
The TFTP Read Request packet is modified to include the multicast
option as follows:
+--------+----~~----+---+--~~--+---+-----------+---+---+
| opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
+--------+----~~----+---+--~~--+---+-----------+---+---+
opc
The opcode field contains a 1, for Read Requests, as defined
in [1].
Emberson Experimental [Page 1]
RFC 2090 TFTP Multicast Option February 1997
filename
The name of the file to be read, as defined in [1]. This is a
NULL-terminated field.
mode
The mode of the file transfer: "netascii", "octet", or
"mail", as defined in [1]. This is a NULL-terminated field.
multicast
Request for multicast transmission of the file option,
"multicast" (case insensitive). This is a NULL-terminated
field. The value for this option request is a string of zero
length.
If the server is willing to accept the multicast option, it
sends an Option Acknowledgment (OACK) to the client including
the multicast option, as defined in [2]. The OACK to the client
will specify the multicast address and flag to indicate whether
that client should send block acknowledgments (ACK).
+-------+-----------+---+-------~~-------+---+
| opc | multicast | 0 | addr, port, mc | 0 |
+-------+-----------+---+-------~~-------+---+
opc
The opcode field contains the number 6, for Option
Acknowledgment, as defined in [2].
multicast
Acknowledges the multicast option. This is a NULL-terminated
field.
addr
The addr field contains the multicast IP address. This field
is terminated with a comma.
port
The port field contains the destination port of the multicast
packets. The use of Registered Port number 1758 (tftp-mcast)
is recommended. This field is terminated with a comma.
mc
This field will be either 0 or 1, to tell the client whether
it is the master client, that is, it is responsible for
sending ACKs to the server. This is NULL-terminated field.
Emberson Experimental [Page 2]
RFC 2090 TFTP Multicast Option February 1997
Data Transfer
After the OACK is received by the client it will send an ACK for
packet zero, as in [2]. With the multicast option being accepted this
ACK will indicate to the server that the client wants the first
packet. In other words the ACKs may now be seen as a request for the
n+1th block of data. This enables each a client to request any block
within the file that it may be missing.
To manage the data transfer the server will maintain a list of
clients. Typically the oldest client on the list, from here on
referred to as the Master Client, will be responsible for sending
ACKs. When the master client is finished, the server will send
another OACK to the next oldest client, telling it to start sending
ACKs. Upon receipt of this OACK the new master client will send an
ACK for the block immediately before the first block required to
complete its download.
Any subsequent clients can start receiving blocks of a file during a
transfer and then request any missing blocks when that client becomes
the master client. When the current master client is finished, the
server will notify the next client with an OACK making it the new
master client. The new master client can start requesting missed
packets. Each client must terminate the transfer by sending an
acknowledgment of the last packet or by sending an error message to
server. This termination can occur even if the client is not the
master client.
Any subsequent OACKs to a client may have an empty multicast address
and port fields, since this information will already be held by that
client. In the event a client fails to respond in a timely manner to
a OACK enabling it as the master client, the server shall select the
next oldest client to be the master client. The server shall
reattempt to send a OACK to the non- responding client when the new
master client is finished. The server may cease communication with a
client after a reasonable number of attempts.
Each transfer will be given a multicast address for use to distribute
the data packets. Since there can be multiple servers on a given
network or a limited number of addresses available to a given server,
it is possible that their might be more than one transfer using a
multicast address. To ensure that a client only accepts the correct
packets, each transfer must use a unique port on the server. The
source IP address and port number will identify the data packets for
the transfer. Thus the server must send the unicast OACK packet to
the client using the same port as will be used for sending the
multicast data packets.
Emberson Experimental [Page 3]
RFC 2090 TFTP Multicast Option February 1997
At any point if a client, other than the master client, sends a ACK
to the server, the server will respond with another OACK with the mc
field holding a value of zero. If this client persists in sending
erroneous ACKs, the server may send an error packet to the client,
discontinuing the file transfer for that client.
The server may also send unicast packets to a lone client to reduce
adverse effects on other machines. As it is possible that machines
may be forced to process many extraneous multicast packets when
attempting to receive a single multicast address.
Example
clients server message
------------------------------------------------------------
1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ
2 C1 <- |6|multicast|224.100.100.100,1758,1| OACK
3 C1 |4|0| -> ACK
4 M <- |3|1|1| 512 octets of data| DATA
5 C1 |4|1| -> ACK
6 M <- |3|2|1| 512 octets of data| DATA
7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ
8 C2 <- |6|multicast|224.100.100.100,1758,0| OACK
9 C2 |4|0| -> ACK
10 C1 |4|2| -> ACK
11 M <- |3|3|1| 512 octets of data| DATA
12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ
13 C3 <- |6|multicast|224.100.100.100,1758,0| OACK
14 C1 |4|3| -> ACK
15 C2 |4|0| -> ACK
16 M (except C2) <- |3|4|1| 512 octets of data| DATA
17 C1 |4|4| -> ACK
18 M <- |3|5|1| 512 octets of data| DATA
19 C1 |4|5| -> ACK
20 M <- |3|6|1| 100 octets of data| DATA
21 C1 |4|6| -> ACK
22 C2 <- |6|multicast|,,1| OACK
23 C2 |4|0| -> ACK
24 M <- |3|1|1| 512 octets of data| DATA
25 C2 |4|1| -> ACK
26 M <- |3|2|1| 512 octets of data| DATA
27 C2 |4|3| -> ACK
28 M <- |3|4|1| 512 octets of data| DATA
29 C2 |4|6| -> ACK
30 C3 <- |6|multicast|,,1| OACK
31 C3 |4|2| -> ACK
32 M <- |3|3|1| 512 octets of data| DATA
33 C3 |4|6| -> ACK
Emberson Experimental [Page 4]
RFC 2090 TFTP Multicast Option February 1997
Comments:
1 request from client 1
2 option acknowledgment
3 acknowledgment for option acknowledgment,
or request for first block of data
4 first data packet sent to the multicast address
7 request from client 2
8 option acknowledgment to client 2,
send no acknowledgments
9 OACK acknowledgment from client 2
15 OACK acknowledgment from client 3
16 client 2 fails to receive a packet
21 client 1 acknowledges receipt of the last block,
telling the server it is done
23 option acknowledgment to client 2,
now the master client
25 client 2 acknowledging with request for first block
27 client 2 acknowledges with request for missed block
29 client 2 signals it is finished
31 client 3 is master client and asks for missing blocks
33 client 3 signals it is finished
Conclusion
With the use of the multicast and blocksize[3] options TFTP will be
capable of fast and efficient downloads of data. Using TFTP with the
multicast option will maintain backward compatibility for both
clients and servers.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
1350, MIT, July 1992.
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC
1782, Xylogics, Inc., Hewlett Packard Co., March 1995.
[3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC
1783, Xylogics, Inc., Hewlett Packard Co., March 1995.
Emberson Experimental [Page 5]
RFC 2090 TFTP Multicast Option February 1997
Author's Address
A. Thomas Emberson
Lanworks Technologies, Inc.
2425 Skymark Avenue
Mississauga, Ontario
Canada L4W 4Y6
Phone: (905) 238-5528
EMail: tom@lanworks.com
Emberson Experimental [Page 6]

395
sources/DSS/rfc/rfc2347.txt Normal file
View File

@ -0,0 +1,395 @@
Network Working Group G. Malkin
Request for Commments: 2347 Bay Networks
Updates: 1350 A. Harkin
Obsoletes: 1782 Hewlett Packard Co.
Category: Standards Track May 1998
TFTP Option Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host. This document describes a simple extension to TFTP to
allow option negotiation prior to the file transfer.
Introduction
The option negotiation mechanism proposed in this document is a
backward-compatible extension to the TFTP protocol. It allows file
transfer options to be negotiated prior to the transfer using a
mechanism which is consistent with TFTP's Request Packet format. The
mechanism is kept simple by enforcing a request-respond-acknowledge
sequence, similar to the lock-step approach taken by TFTP itself.
While the option negotiation mechanism is general purpose, in that
many types of options may be negotiated, it was created to support
the Blocksize option defined in [2]. Additional options are defined
in [3].
Packet Formats
TFTP options are appended to the Read Request and Write Request
packets. A new type of TFTP packet, the Option Acknowledgment
(OACK), is used to acknowledge a client's option negotiation request.
A new error code, 8, is hereby defined to indicate that a transfer
Malkin & Harkin Standards Track [Page 1]
RFC 2347 TFTP Option Extension May 1998
should be terminated due to option negotiation.
Options are appended to a TFTP Read Request or Write Request packet
as follows:
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
>-------+---+---~~---+---+
< optN | 0 | valueN | 0 |
>-------+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
filename
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field.
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field.
opt1
The first option, in case-insensitive ASCII (e.g., blksize).
This is a NULL-terminated field.
value1
The value associated with the first option, in case-
insensitive ASCII. This is a NULL-terminated field.
optN, valueN
The final option/value pair. Each NULL-terminated field is
specified in case-insensitive ASCII.
The options and values are all NULL-terminated, in keeping with the
original request format. If multiple options are to be negotiated,
they are appended to each other. The order in which options are
specified is not significant. The maximum size of a request packet
is 512 octets.
The OACK packet has the following format:
Malkin & Harkin Standards Track [Page 2]
RFC 2347 TFTP Option Extension May 1998
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| 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.
Negotiation Protocol
The client appends options at the end of the Read Request or Write
request packet, as shown above. Any number of options may be
specified; however, an option may only be specified once. The order
of the options is not significant.
If the server supports option negotiation, and it recognizes one or
more of the options specified in the request packet, the server may
respond with an Options Acknowledgment (OACK). Each option the
server recognizes, and accepts the value for, is included in the
OACK. Some options may allow alternate values to be proposed, but
this is an option specific feature. The server must not include in
the OACK any option which had not been specifically requested by the
client; that is, only the client may initiate option negotiation.
Options which the server does not support should be omitted from the
OACK; they should not cause an ERROR packet to be generated. If the
value of a supported option is invalid, the specification for that
option will indicate whether the server should simply omit the option
from the OACK, respond with an alternate value, or send an ERROR
packet, with error code 8, to terminate the transfer.
An option not acknowledged by the server must be ignored by the
client and server as if it were never requested. If multiple options
were requested, the client must use those options which were
acknowledged by the server and must not use those options which were
not acknowledged by the server.
Malkin & Harkin Standards Track [Page 3]
RFC 2347 TFTP Option Extension May 1998
When the client appends options to the end of a Read Request packet,
three possible responses may be returned by the server:
OACK - acknowledge of Read Request and the options;
DATA - acknowledge of Read Request, but not the options;
ERROR - the request has been denied.
When the client appends options to the end of a Write Request packet,
three possible responses may be returned by the server:
OACK - acknowledge of Write Request and the options;
ACK - acknowledge of Write Request, but not the options;
ERROR - the request has been denied.
If a server implementation does not support option negotiation, it
will likely ignore any options appended to the client's request. In
this case, the server will return a DATA packet for a Read Request
and an ACK packet for a Write Request establishing normal TFTP data
transfer. In the event that a server returns an error for a request
which carries an option, the client may attempt to repeat the request
without appending any options. This implementation option would
handle servers which consider extraneous data in the request packet
to be erroneous.
Depending on the original transfer request there are two ways for a
client to confirm acceptance of a server's OACK. If the transfer was
initiated with a Read Request, then an ACK (with the data block
number set to 0) is sent by the client to confirm the values in the
server's OACK packet. If the transfer was initiated with a Write
Request, then the client begins the transfer with the first DATA
packet, using the negotiated values. If the client rejects the OACK,
then it sends an ERROR packet, with error code 8, to the server and
the transfer is terminated.
Once a client acknowledges an OACK, with an appropriate non-error
response, that client has agreed to use only the options and values
returned by the server. Remember that the server cannot request an
option; it can only respond to them. If the client receives an OACK
containing an unrequested option, it should respond with an ERROR
packet, with error code 8, and terminate the transfer.
Malkin & Harkin Standards Track [Page 4]
RFC 2347 TFTP Option Extension May 1998
Examples
Read Request
client server
-------------------------------------------------------
|1|foofile|0|octet|0|blksize|0|1432|0| --> RRQ
<-- |6|blksize|0|1432|0| OACK
|4|0| --> ACK
<-- |3|1| 1432 octets of data | DATA
|4|1| --> ACK
<-- |3|2| 1432 octets of data | DATA
|4|2| --> ACK
<-- |3|3|<1432 octets of data | DATA
|4|3| --> ACK
Write Request
client server
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| --> RRQ
<-- |6|blksize|0|2048|0| OACK
|3|1| 2048 octets of data | --> DATA
<-- |4|1| ACK
|3|2| 2048 octets of data | --> DATA
<-- |4|2| ACK
|3|3|<2048 octets of data | --> DATA
<-- |4|3| ACK
Security Considerations
The basic TFTP protocol has no security mechanism. This is why it
has no rename, delete, or file overwrite capabilities. This document
does not add any security to TFTP; however, the specified extensions
do not add any additional security risks.
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
May 1998.
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
Size Options", RFC 2349, May 1998.
Malkin & Harkin Standards Track [Page 5]
RFC 2347 TFTP Option Extension May 1998
Authors' Addresses
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.com
Art Harkin
Internet Services Project
Information Networks Division
19420 Homestead Road MS 43LN
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 6]
RFC 2347 TFTP Option Extension May 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Malkin & Harkin Standards Track [Page 7]

283
sources/DSS/rfc/rfc2348.txt Normal file
View File

@ -0,0 +1,283 @@
Network Working Group G. Malkin
Request for Commments: 2348 Bay Networks
Updates: 1350 A. Harkin
Obsoletes: 1783 Hewlett Packard Co.
Category: Standards Track May 1998
TFTP Blocksize Option
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host. One of its primary uses is the booting of diskless
nodes on a Local Area Network. TFTP is used because it is very
simple to implement in a small node's limited ROM space. However,
the choice of a 512-octet blocksize is not the most efficient for use
on a LAN whose MTU may 1500 octets or greater.
This document describes a TFTP option which allows the client and
server to negotiate a blocksize more applicable to the network
medium. The TFTP Option Extension mechanism is described in [2].
Blocksize Option Specification
The TFTP Read Request or Write Request packet is modified to include
the blocksize option as follows. Note that all fields except "opc"
are NULL-terminated.
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
Malkin & Harkin Standards Track [Page 1]
RFC 2348 TFTP Blocksize Option May 1998
filename
The name of the file to be read or written, as defined in [1].
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1].
blksize
The Blocksize option, "blksize" (case in-sensitive).
#octets
The number of octets in a block, specified in ASCII. Valid
values range between "8" and "65464" octets, inclusive. The
blocksize refers to the number of data octets; it does not
include the four octets of TFTP header.
For example:
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary)
transfer mode, with a block size of 1428 octets (Ethernet MTU, less
the TFTP, UDP and IP header lengths).
If the server is willing to accept the blocksize option, it sends an
Option Acknowledgment (OACK) to the client. The specified value must
be less than or equal to the value specified by the client. The
client must then either use the size specified in the OACK, or send
an ERROR packet, with error code 8, to terminate the transfer.
The rules for determining the final packet are unchanged from [1].
The reception of a data packet with a data length less than the
negotiated blocksize is the final packet. If the blocksize is
greater than the amount of data to be transfered, the first packet is
the final packet. If the amount of data to be transfered is an
integral multiple of the blocksize, an extra data packet containing
no data is sent to end the transfer.
Proof of Concept
Performance tests were run on the prototype implementation using a
variety of block sizes. The tests were run on a lightly loaded
Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files.
The average (5x) transfer times for paths with (g-time) and without
(n-time) a intermediate gateway are graphed as follows:
Malkin & Harkin Standards Track [Page 2]
RFC 2348 TFTP Blocksize Option May 1998
|
37 + g
|
35 +
|
33 +
|
31 +
|
29 +
|
27 +
| g blocksize n-time g-time
25 + --------- ------ ------
s | n 512 23.85 37.05
e 23 + g 1024 16.15 25.65
c | 1428 13.70 23.10
o 21 + 2048 10.90 16.90
n | 4096 6.85 9.65
d 19 + 8192 4.90 6.15
s |
17 + g
| n
15 +
| n
13 +
|
11 + n
| g
9 +
|
7 + n
| g
5 + n
"
0 +------+------+--+---+------+------+---
512 1K | 2K 4K 8K
1428
blocksize (octets)
The comparisons between transfer times (without a gateway) between
the standard 512-octet blocksize and the negotiated blocksizes are:
1024 2x -32%
1428 2.8x -42%
2048 4x -54%
4096 8x -71%
8192 16x -80%
Malkin & Harkin Standards Track [Page 3]
RFC 2348 TFTP Blocksize Option May 1998
As was anticipated, the transfer time decreases with an increase in
blocksize. The reason for the reduction in time is the reduction in
the number of packets sent. For example, by increasing the blocksize
from 512 octets to 1024 octets, not only are the number of data
packets halved, but the number of acknowledgement packets is also
halved (along with the number of times the data transmitter must wait
for an ACK). A secondary effect is the efficiency gained by reducing
the per-packet framing and processing overhead.
Of course, if the blocksize exceeds the path MTU, IP fragmentation
and reassembly will begin to add more overhead. This will be more
noticable the greater the number of gateways in the path.
Security Considerations
The basic TFTP protocol has no security mechanism. This is why it
has no rename, delete, or file overwrite capabilities. This document
does not add any security to TFTP; however, the specified extensions
do not add any additional security risks.
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
May 1998.
Authors' Addresses
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 10821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.com
Art Harkin
Networked Computing Division
Hewlett-Packard Company
19420 Homestead Road MS 43LN
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 4]
RFC 2348 TFTP Blocksize Option May 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Malkin & Harkin Standards Track [Page 5]

283
sources/DSS/rfc/rfc2349.txt Normal file
View File

@ -0,0 +1,283 @@
Network Working Group G. Malkin
Request for Commments: 2349 Bay Networks
Updates: 1350 A. Harkin
Obsoletes: 1784 Hewlett Packard Co.
Category: Standards Track May 1998
TFTP Timeout Interval and Transfer Size Options
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host.
This document describes two TFTP options. The first allows the client
and server to negotiate the Timeout Interval. The second allows the
side receiving the file to determine the ultimate size of the
transfer before it begins. The TFTP Option Extension mechanism is
described in [2].
Timeout Interval Option Specification
The TFTP Read Request or Write Request packet is modified to include
the timeout option as follows:
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | timeout| 0 | #secs | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
Malkin & Harkin Standards Track [Page 1]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
filename
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field.
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field.
timeout
The Timeout Interval option, "timeout" (case in-sensitive).
This is a NULL-terminated field.
#secs
The number of seconds to wait before retransmitting, specified
in ASCII. Valid values range between "1" and "255" seconds,
inclusive. This is a NULL-terminated field.
For example:
+-------+--------+---+--------+---+--------+---+-------+---+
| 1 | foobar | 0 | octet | 0 | timeout| 0 | 1 | 0 |
+-------+--------+---+--------+---+--------+---+-------+---+
is a Read Request, for the file named "foobar", in octet (binary)
transfer mode, with a timeout interval of 1 second.
If the server is willing to accept the timeout option, it sends an
Option Acknowledgment (OACK) to the client. The specified timeout
value must match the value specified by the client.
Transfer Size Option Specification
The TFTP Read Request or Write Request packet is modified to include
the tsize option as follows:
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | tsize | 0 | size | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
filename
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field.
Malkin & Harkin Standards Track [Page 2]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field.
tsize
The Transfer Size option, "tsize" (case in-sensitive). This is
a NULL-terminated field.
size
The size of the file to be transfered. This is a NULL-
terminated field.
For example:
+-------+--------+---+--------+---+--------+---+--------+---+
| 2 | foobar | 0 | octet | 0 | tsize | 0 | 673312 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Write Request, with the 673312-octet file named "foobar", in
octet (binary) transfer mode.
In Read Request packets, a size of "0" is specified in the request
and the size of the file, in octets, is returned in the OACK. If the
file is too large for the client to handle, it may abort the transfer
with an Error packet (error code 3). In Write Request packets, the
size of the file, in octets, is specified in the request and echoed
back in the OACK. If the file is too large for the server to handle,
it may abort the transfer with an Error packet (error code 3).
Security Considerations
The basic TFTP protocol has no security mechanism. This is why it
has no rename, delete, or file overwrite capabilities. This document
does not add any security to TFTP; however, the specified extensions
do not add any additional security risks.
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 92.
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
May 1998.
Malkin & Harkin Standards Track [Page 3]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
Authors' Addresses
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.com
Art Harkin
Internet Services Project
Information Networks Division
19420 Homestead Road MS 43LN
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 4]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Malkin & Harkin Standards Track [Page 5]

507
sources/DSS/rfc/rfc7440.txt Normal file
View File

@ -0,0 +1,507 @@
Internet Engineering Task Force (IETF) P. Masotta
Request for Comments: 7440 Serva
Category: Standards Track January 2015
ISSN: 2070-1721
TFTP Windowsize Option
Abstract
The "Trivial File Transfer Protocol" (RFC 1350) is a simple,
lockstep, file transfer protocol that allows a client to get or put a
file onto a remote host. One of its primary uses is in the early
stages of nodes booting from a Local Area Network (LAN). TFTP has
been used for this application because it is very simple to
implement. The employment of a lockstep scheme limits throughput
when used on a LAN.
This document describes a TFTP option that allows the client and
server to negotiate a window size of consecutive blocks to send as an
alternative for replacing the single-block lockstep schema. The TFTP
option mechanism employed is described in "TFTP Option Extension"
(RFC 2347).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7440.
Masotta Standards Track [Page 1]
RFC 7440 TFTP Windowsize Option January 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Windowsize Option Specification .................................3
4. Traffic Flow and Error Handling .................................4
5. Proof of Concept and Windowsize Evaluation ......................6
6. Congestion and Error Control ....................................7
7. Security Considerations .........................................8
8. References ......................................................9
8.1. Normative References .......................................9
Author's Address ...................................................9
1. Introduction
TFTP is virtually unused for Internet transfers today, TFTP is still
massively used in network boot/installation scenarios including EFI
(Extensible Firmware Interface). TFTP's inherently low transfer rate
has been, so far, partially mitigated by the use of the blocksize
negotiated extension [RFC2348]. Using this method, the original
limitation of 512-byte blocks are, in practice, replaced in Ethernet
environments by blocks no larger than 1468 Bytes to avoid IP block
fragmentation. This strategy produces insufficient results when
transferring big files, for example, the initial ramdisk of Linux
distributions or the PE images used in network installations by
Microsoft WDS/MDT/SCCM. Considering TFTP looks far from extinction
today, this document presents a negotiated extension, under the terms
of the "TFTP Option Extension" [RFC2347], that produces TFTP transfer
rates comparable to those achieved by modern file transfer protocols.
Masotta Standards Track [Page 2]
RFC 7440 TFTP Windowsize Option January 2015
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lowercase uses of these words are not to be
interpreted as carrying the significance given in RFC 2119.
3. Windowsize Option Specification
The TFTP Read Request or Write Request packet is modified to include
the windowsize option as follows. Note that all fields except "opc"
MUST be ASCII strings followed by a single-byte NULL character.
2B string 1B string 1B string 1B string 1B
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
| opc |filename| 0 | mode | 0 | windowsize | 0 | #blocks| 0 |
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
opc
The opcode field contains either a 1 for Read Requests or a 2 for
Write Requests, as defined in [RFC1350].
filename
The name of the file to be read or written, as defined in
[RFC1350].
mode
The mode of the file transfer: "netascii", "octet", or "mail", as
defined in [RFC1350].
windowsize
The windowsize option, "windowsize" (case insensitive).
#blocks
The base-10 ASCII string representation of the number of blocks in
a window. The valid values range MUST be between 1 and 65535
blocks, inclusive. The windowsize refers to the number of
consecutive blocks transmitted before stopping and waiting for the
reception of the acknowledgment of the last block transmitted.
Masotta Standards Track [Page 3]
RFC 7440 TFTP Windowsize Option January 2015
For example:
+------+--------+----+-------+----+------------+----+----+----+
|0x0001| foobar |0x00| octet |0x00| windowsize |0x00| 16 |0x00|
+------+--------+----+-------+----+------------+----+----+----+
is a Read Request for the file named "foobar" in octet transfer mode
with a windowsize of 16 blocks (option blocksize is not negotiated in
this example, the default of 512 Bytes per block applies).
If the server is willing to accept the windowsize option, it sends an
Option Acknowledgment (OACK) to the client. The specified value MUST
be less than or equal to the value specified by the client. The
client MUST then either use the size specified in the OACK or send an
ERROR packet, with error code 8, to terminate the transfer.
The rules for determining the final packet are unchanged from
[RFC1350] and [RFC2348].
The reception of a data window with a number of blocks less than the
negotiated windowsize is the final window. If the windowsize is
greater than the amount of data to be transferred, the first window
is the final window.
4. Traffic Flow and Error Handling
The next diagram depicts a section of the traffic flow between the
Data Sender (DSND) and the Data Receiver (DRCV) parties on a generic
windowsize TFTP file transfer.
The DSND MUST cyclically send to the DRCV the agreed windowsize
consecutive data blocks before normally stopping and waiting for the
ACK of the transferred window. The DRCV MUST send to the DSND the
ACK of the last data block of the window in order to confirm a
successful data block window reception.
In the case of an expected ACK not timely reaching the DSND
(timeout), the last received ACK SHALL set the beginning of the next
windowsize data block window to be sent.
In the case of a data block sequence error, the DRCV SHOULD notify
the DSND by sending an ACK corresponding to the last data block
correctly received. The notified DSND SHOULD send a new data block
window whose beginning MUST be set based on the ACK received out of
sequence.
Traffic with windowsize = 1 MUST be equivalent to traffic specified
by [RFC1350].
Masotta Standards Track [Page 4]
RFC 7440 TFTP Windowsize Option January 2015
For normative traffic not specifically addressed in this section,
please refer to [RFC1350] and its updates.
[ DRCV ] <---traffic---> [ DSND ]
ACK# -> <- Data Block# window block#
...
<- |DB n+01| 1
<- |DB n+02| 2
<- |DB n+03| 3
<- |DB n+04| 4
|ACK n+04| ->
<- |DB n+05| 1
Error |<- |DB n+06| 2
<- |DB n+07| 3
|ACK n+05| ->
<- |DB n+06| 1
<- |DB n+07| 2
<- |DB n+08| 3
<- |DB n+09| 4
|ACK n+09| ->
<- |DB n+10| 1
Error |<- |DB n+11| 2
<- |DB n+12| 3
|ACK n+10| ->| Error
<- |DB n+13| 4
- timeout -
<- |DB n+10| 1
<- |DB n+11| 2
<- |DB n+12| 3
<- |DB n+13| 4
|ACK n+13| ->
...
Section of a Windowsize = 4 TFTP Transfer
Including Errors and Error Recovery
Masotta Standards Track [Page 5]
RFC 7440 TFTP Windowsize Option January 2015
5. Proof of Concept and Windowsize Evaluation
Performance tests were run on the prototype implementation using a
variety of windowsizes and a fixed blocksize of 1456 bytes. The
tests were run on a lightly loaded Gigabit Ethernet, between two
Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
transferring a 180 MByte file.
^
|
300 +
Seconds | windowsize | time (s)
| ---------- ------
| x 1 257
250 + 2 131
| 4 76
| 8 54
| 16 42
200 + 32 38
| 64 35
|
|
150 +
|
| x
|
100 +
|
| x
|
50 + x
| x
| x x
|
0 +-//--+-----+-----+-----+-----+-----+-----+-->
1 2 4 8 16 32 64
Windowsize (in Blocks of 1456 Bytes)
Comparatively, the same 180 MB transfer performed over a drive mapped
on Server Message Block (SMB) / Common Internet File System (CIFS) on
the same scenario took 23 seconds.
Masotta Standards Track [Page 6]
RFC 7440 TFTP Windowsize Option January 2015
The comparison of transfer times (without a gateway) between the
standard lockstep schema and the negotiated windowsizes are:
Windowsize | Time Reduction (%)
---------- -----------------
1 -0%
2 -49%
4 -70%
8 -79%
16 -84%
32 -85%
64 -86%
The transfer time decreases with the use of a windowed schema. The
reason for the reduction in time is the reduction in the number of
the required synchronous acknowledgements exchanged.
The choice of appropriate windowsize values on a particular scenario
depends on the underlying networking technology and topology, and
likely other factors as well. Operators SHOULD test various values
and SHOULD be conservative when selecting a windowsize value because
as the former table and chart shows, there is a point where the
benefit of continuing to increase the windowsize is subject to
diminishing returns.
6. Congestion and Error Control
From a congestion control (CC) standpoint, the number of blocks in a
window does not pose an intrinsic threat to the ability of
intermediate devices to signal congestion through drops. The rate at
which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in
Section 3.1 of [RFC5405].
From an error control standpoint, while [RFC1350] and subsequent
updates do not specify a circuit breaker (CB), existing
implementations have always chosen to fail under certain
circumstances. Implementations SHOULD always set a maximum number of
retries for datagram retransmissions, imposing an appropriate
threshold on error recovery attempts, after which a transfer SHOULD
always be aborted to prevent pathological retransmission conditions.
Masotta Standards Track [Page 7]
RFC 7440 TFTP Windowsize Option January 2015
An implementation example scaled for an Ethernet environment
(1 Gbit/s, MTU=1500) would be to set:
windowsize = 8
blksize = 1456
maximum retransmission attempts per block/window = 6
timeout between retransmissions = 1 S
minimum inter-packet delay = 80 uS
Implementations might well choose other values based on expected
and/or tested operating conditions.
7. Security Considerations
TFTP includes no login or access control mechanisms. Care must be
taken when using TFTP for file transfers where authentication, access
control, confidentiality, or integrity checking are needed. Note
that those security services could be supplied above or below the
layer at which TFTP runs. Care must also be taken in the rights
granted to a TFTP server process so as not to violate the security of
the server's file system. TFTP is often installed with controls such
that only files that have public read access are available via TFTP.
Also listing, deleting, renaming, and writing files via TFTP are
typically disallowed. TFTP file transfers are NOT RECOMMENDED where
the inherent protocol limitations could raise insurmountable
liability concerns.
TFTP includes no protection against an on-path attacker; care must be
taken in controlling windowsize values according to data sender, data
receiver, and network environment capabilities. TFTP service is
frequently associated with bootstrap and initial provisioning
activities; servers in such an environment are in a position to
impose device or network specific throughput limitations as
appropriate.
This document does not add any security controls to TFTP; however,
the specified extension does not pose additional security risks
either.
Masotta Standards Track [Page 8]
RFC 7440 TFTP Windowsize Option January 2015
8. References
8.1. Normative References
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992,
<http://www.rfc-editor.org/info/rfc1350>.
[RFC2347] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC
2347, May 1998, <http://www.rfc-editor.org/info/rfc2347>.
[RFC2348] Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC
2348, May 1998, <http://www.rfc-editor.org/info/rfc2348>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
Guidelines for Application Designers", BCP 145, RFC 5405,
November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Author's Address
Patrick Masotta
Serva
EMail: patrick.masotta.ietf@vercot.com
URI: http://www.vercot.com/~serva/
Masotta Standards Track [Page 9]

5
sources/DSS/sprinter.inc
View File

@ -4,6 +4,9 @@
; https://github.com/romychs
; ======================================================
IFNDEF _SPRINTER
DEFINE _SPRINTER
; Memory pages
PAGE0_ADDR EQU 0x0000
PAGE1_ADDR EQU 0x4000
@ -30,3 +33,5 @@ CTC_CT_TRE EQU 0x10 ; 1 - Trigger Edge
CTC_CT_PRE EQU 0x20 ; 1 - 256 Prescaler, 0 - 16
CTC_CT_CTR EQU 0x40 ; 0 - Timer, 1 - Counter
CTC_CT_EI EQU 0x80 ; Interrupt 1 - enable, 0 - disable
ENDIF

119
sources/DSS/util.asm
View File

@ -5,6 +5,9 @@
; License: BSD 3-Clause
; ======================================================
IFNDEF _UTIL_ASM
DEFINE _UTIL_ASM
MODULE UTIL
; ------------------------------------------------------
@ -29,8 +32,6 @@ DELAY_NXT
POP HL,BC,AF
RET
DELAY_1MS_INT
LD BC,400
SBD_NXT
@ -40,15 +41,18 @@ SBD_NXT
JR NZ, SBD_NXT
RET
; ------------------------------------------------------
; Delay for about 1ms
; ------------------------------------------------------
DELAY_1MS
PUSH BC
CALL DELAY_1MS_INT
POP BC
RET
; ------------------------------------------------------
; Delay for about 100us
; ------------------------------------------------------
DELAY_100uS
PUSH BC
LD BC,40
@ -56,12 +60,12 @@ DELAY_100uS
POP BC
RET
; ------------------------------------------------------
; Calc length of zero ended string
; Inp: HL - pointer to string
; Out: BC - length of string
; ------------------------------------------------------
IFUSED STRLEN
STRLEN
PUSH DE,HL,HL
LD BC,MAX_BUFF_SIZE
@ -77,12 +81,14 @@ STRLEN
STRL_NCOR
POP HL,DE
RET
ENDIF
; ------------------------------------------------------
; Compare zero-ended strings
; Inp: HL, DE - pointers to strinngs to compare
; Inp: HL, DE - pointers to strings to compare
; Out: CF=0 - equal, CF=1 - not equal
; ------------------------------------------------------
IFUSED STRCMP
STRCMP
PUSH DE,HL
STC_NEXT
@ -99,12 +105,69 @@ STC_NE
STC_EQ
POP HL,DE
RET
ENDIF
; ------------------------------------------------------
; Compare first BC chars for two zero-ended strings
; Inp: HL, DE - pointers to strings to compare
; BC - Number of chars to compare
; Out: ZF=0 - not equal, ZF=1 - equal
; ------------------------------------------------------
IFUSED STRNCMP
STRNCMP
PUSH HL,DE,BC
.STRN_NXT
LD A,(DE)
SUB (HL)
JR NZ,.STRN_NE
LD A,(DE)
OR A
JR Z,.STRN_NE
INC DE
INC HL
DEC BC
LD A,B
OR C
JP NZ,.STRN_NXT
.STRN_NE
POP BC,DE,HL
RET
ENDIF
; ------------------------------------------------------
; Checks whether a string (HL) starts with the strinf (DE)
; Inp: DE - points to start string
; HL - points to string
; Out: ZF=0 - not equal, ZF=1 - equal
; ------------------------------------------------------
IFUSED STARTSWITH
STARTSWITH
PUSH HL,DE
.STRW_NXT
LD A,(DE)
OR A
JR Z,.STRW_END
LD A,(DE)
CP (HL)
JR NZ,.STRW_END
INC HL
INC DE
JR .STRW_NXT
.STRW_END
POP DE,HL
RET
ENDIF
; ------------------------------------------------------
; Convert string to number
; Inp: DE - ptr to zero ended string
; Out: HL - Result
; ------------------------------------------------------
IFUSED ATOU
ATOU
PUSH BC
LD HL,0x0000
@ -130,7 +193,7 @@ ATOU_L1
ATOU_LE
POP BC
RET
ENDIF
; ------------------------------------------------------
; Find char in string
@ -139,6 +202,7 @@ ATOU_LE
; Outp: CF=0, HL points to char if found
; CF=1 - Not found
; ------------------------------------------------------
IFUSED STRCHR
STRCHR
PUSH BC
STCH_NEXT
@ -155,30 +219,33 @@ STCH_N_FOUND
STCH_FOUND
POP BC
RET
ENDIF
; ------------------------------------------------------
; Convert Byte to hex
; Inp: C
; Out: (DE)
; ------------------------------------------------------
IFUSED HEXB
HEXB
LD A,C
RRA
RRA
RRA
RRA
CALL CONV_NIBLE
LD A,C
LD A,C
RRA
RRA
RRA
RRA
CALL CONV_NIBLE
LD A,C
CONV_NIBLE
AND 0x0f
ADD A,0x90
DAA
ADC A,0x40
DAA
LD (DE), A
INC DE
RET
AND 0x0f
ADD A,0x90
DAA
ADC A,0x40
DAA
LD (DE), A
INC DE
RET
ENDIF
ENDMODULE
ENDMODULE
ENDIF

104
sources/DSS/wcommon.asm
View File

@ -12,7 +12,7 @@ ENABLE_RTS_CTR EQU 1
; ------------------------------------------------------
; Ckeck for error (CF=1) print message and exit
; ------------------------------------------------------
IFUSED CHECK_ERROR
CHECK_ERROR
RET NC
ADD A,'0'
@ -21,18 +21,23 @@ CHECK_ERROR
CALL DUMP_UART_REGS
LD B,3
POP HL ; ret addr reset
ENDIF
; ------------------------------------------------------
; Program exit point
; ------------------------------------------------------
IFUSED EXIT
EXIT
CALL REST_VMODE
LD C,DSS_EXIT
RST DSS
ENDIF
; ------------------------------------------------------
; Search Sprinter WiFi card
; ------------------------------------------------------
IFUSED FIND_SWF
FIND_SWF
; Find Sprinter-WiFi
CALL WIFI.UART_FIND
CALL @WIFI.UART_FIND
JP C, NO_TL_FOUND
LD A,(ISA.ISA_SLOT)
ADD A,'1'
@ -45,57 +50,59 @@ NO_TL_FOUND
PRINTLN MSG_SWF_NOF
LD B,2
JP EXIT
ENDIF
IF TRACE
; ------------------------------------------------------
; Dump all UTL16C550 registers to screen for debug
; ------------------------------------------------------
IFUSED DUMP_UART_REGS
IF TRACE
DUMP_UART_REGS
; Dump, DLAB=0 registers
LD BC, 0x0800
CALL DUMP_REGS
; Dump, DLAB=0 registers
LD BC, 0x0800
CALL DUMP_REGS
; Dump, DLAB=1 registers
LD HL, REG_LCR
LD E, LCR_DLAB | LCR_WL8
CALL WIFI.UART_WRITE
LD BC, 0x0210
CALL DUMP_REGS
; Dump, DLAB=1 registers
LD HL, REG_LCR
LD E, LCR_DLAB | LCR_WL8
CALL WIFI.UART_WRITE
LD BC, 0x0210
CALL DUMP_REGS
LD HL, REG_LCR
LD E, LCR_WL8
CALL WIFI.UART_WRITE
RET
LD HL, REG_LCR
LD E, LCR_WL8
CALL WIFI.UART_WRITE
RET
DUMP_REGS
LD HL, PORT_UART_A
LD HL, PORT_UART_A
DR_NEXT
LD DE,MSG_DR_RN
CALL UTIL.HEXB
INC C
LD DE,MSG_DR_RN
CALL @UTIL.HEXB
INC C
CALL WIFI.UART_READ
PUSH BC
LD C,A
LD DE,MSG_DR_RV
CALL UTIL.HEXB
PUSH HL
CALL WIFI.UART_READ
PUSH BC
LD C,A
LD DE,MSG_DR_RV
CALL @UTIL.HEXB
PUSH HL
PRINTLN MSG_DR
PRINTLN MSG_DR
POP HL,BC
INC HL
DJNZ DR_NEXT
RET
POP HL,BC
INC HL
DJNZ DR_NEXT
RET
ENDIF
ENDIF
; ------------------------------------------------------
; Store old video mode, set 80x32 and clear
; ------------------------------------------------------
IFUSED INIT_VMODE
INIT_VMODE
PUSH BC,DE,HL
; Store previous vmode
@ -119,10 +126,11 @@ IVM_ALRDY_80
POP HL,DE,BC
RET
ENDIF
; ------------------------------------------------------
; Restore saved video mode
; ------------------------------------------------------
IFUSED REST_VMODE
REST_VMODE
PUSH BC
LD A,(SAVE_VMODE)
@ -139,13 +147,15 @@ REST_VMODE
RVM_SAME
POP BC
RET
ENDIF
; ------------------------------------------------------
; Init basic parameters of ESP
; ------------------------------------------------------
IFUSED INIT_ESP
INIT_ESP
PUSH BC, DE
LD DE, WIFI.RS_BUFF
LD DE, @WIFI.RS_BUFF
LD BC, DEFAULT_TIMEOUT
TRACELN MSG_ECHO_OFF
@ -166,11 +176,12 @@ INIT_ESP
SEND_CMD CMD_CWLAP_OPT
POP DE,BC
RET
ENDIF
; ------------------------------------------------------
; Set DHCP mode
; Out: CF=1 if error
; ------------------------------------------------------
IFUSED SET_DHCP_MODE
SET_DHCP_MODE
PUSH BC,DE
LD DE, WIFI.RS_BUFF
@ -179,21 +190,23 @@ SET_DHCP_MODE
SEND_CMD CMD_SET_DHCP
POP DE,BC
RET
ENDIF
; ------------------------------------------------------
; Messages
; ------------------------------------------------------
IFUSED FIND_SWF
MSG_SWF_NOF
DB "Sprinter-WiFi not found!",0
MSG_SWF_FOUND
DB "Sprinter-WiFi found in ISA#"
MSG_SLOT_NO
DB "n slot.",0
ENDIF
MSG_COMM_ERROR
DB "Error communication with Sprinter-WiFi #"
COMM_ERROR_NO
DB "n!",0
@ -209,14 +222,15 @@ MSG_UART_INIT
LINE_END
DB "\r\n",0
IFUSED INIT_VMODE
SAVE_VMODE
DB 0
ENDIF
; ------------------------------------------------------
; Debug messages
; ------------------------------------------------------
IF TRACE
MSG_DR
DB "Reg[0x"
MSG_DR_RN
@ -247,8 +261,8 @@ MSG_SET_DHCP
; ------------------------------------------------------
; Commands
; ------------------------------------------------------
CMD_QUIT
DB "QUIT\r",0
; CMD_QUIT
; DB "QUIT\r",0
CMD_VERSION
DB "AT+GMR\r\n",0

37
sources/DSS/wterm.asm
View File

@ -13,15 +13,18 @@ DEBUG EQU 0
; Set to 1 to output TRACE messages
TRACE EQU 1
; Version of EXE file, 1 for DSS 1.70+
EXE_VERSION EQU 0
EXE_VERSION EQU 1
; Timeout to wait ESP response
DEFAULT_TIMEOUT EQU 2000
DEFDEVICE SPRINTER, 0x4000, 256, 0,1,2,3
SLDOPT COMMENT WPMEM, LOGPOINT, ASSERTION
DEVICE NOSLOT64K
DEVICE SPRINTER ;NOSLOT64K
IF DEBUG == 1
INCLUDE "dss.asm"
@ -32,7 +35,7 @@ DEFAULT_TIMEOUT EQU 2000
INCLUDE "macro.inc"
INCLUDE "dss.inc"
INCLUDE "sprinter.inc"
;INCLUDE "sprinter.inc"
MODULE MAIN
@ -66,28 +69,27 @@ START
CALL ISA.ISA_RESET
CALL WCOMMON.INIT_VMODE
CALL @WCOMMON.INIT_VMODE
PRINTLN MSG_START
CALL WCOMMON.FIND_SWF
CALL @WCOMMON.FIND_SWF
PRINTLN WCOMMON.MSG_UART_INIT
CALL WIFI.UART_INIT
CALL @WIFI.UART_INIT
PRINTLN WCOMMON.MSG_ESP_RESET
CALL WIFI.ESP_RESET
CALL @WIFI.ESP_RESET
CALL WCOMMON.INIT_ESP
CALL @WCOMMON.INIT_ESP
PRINTLN MSG_HLP
CALL WIFI.UART_EMPTY_RS
CALL @WIFI.UART_EMPTY_RS
MAIN_LOOP
; handle key pressed
LD C,DSS_SCANKEY
RST DSS
DSS_EXEC DSS_SCANKEY
JP Z,HANDLE_RECEIVE ; if no key pressed
LD A,D
CP 0xAB
@ -114,14 +116,14 @@ CHK_PRINTABLE
; transmitt symbol
TX_SYMBOL
CALL WIFI.UART_TX_BYTE
CALL @WIFI.UART_TX_BYTE
JP C,TX_WARN
LD A, E
CP CR
JR NZ,HANDLE_RECEIVE
; Transmitt LF after CR
LD E,LF
CALL WIFI.UART_TX_BYTE
CALL @WIFI.UART_TX_BYTE
JP C,TX_WARN
; check receiver and handle received bytes
@ -159,13 +161,13 @@ CHK_1F
CHECK_FOR_END
; LD A,(Q_POS)
; CP 5
; JP Z, OK_EXIT
; JP Z, OK_EXITDEFDEVICE <deviceid>, <slot_size $100..$10000>, <page_count 1..1024>[, <slot_0_initial_page>[, ...]]
JP MAIN_LOOP
RX_WARN
LD C,A
LD DE,MSG_LSR_VALUE
CALL UTIL.HEXB
CALL @UTIL.HEXB
PRINTLN MSG_RX_ERROR
CALL WIFI.UART_EMPTY_RS
LD HL,RX_ERR
@ -186,8 +188,7 @@ TX_WARN
PUT_A_CHAR
PUSH BC,DE
LD C,DSS_PUTCHAR
RST DSS
DSS_EXEC DSS_PUTCHAR
POP DE,BC
RET
@ -246,7 +247,7 @@ BUFF_TEST1 DS RS_BUFF_SIZE,0
ENDMODULE
INCLUDE "wcommon.asm"
INCLUDE "util.asm"
;INCLUDE "util.asm"
INCLUDE "isa.asm"
INCLUDE "esplib.asm"

385
sources/DSS/wtftp.asm Normal file
View File

@ -0,0 +1,385 @@
; ======================================================
; WTFTP client for trivial file transfer protocol
; for Sprinter-WiFi ISA Card
; By Roman Boykov. Copyright (c) 2024
; https://github.com/romychs
; License: BSD 3-Clause
; ======================================================
; Set to 1 to turn debug ON with DeZog VSCode plugin
; Set to 0 to compile .EXE
DEBUG EQU 1
; Set to 1 to output TRACE messages
TRACE EQU 1
WM_DOWNLOAD EQU 0
WM_UPLOAD EQU 1
; Version of EXE file, 1 for DSS 1.70+
EXE_VERSION EQU 1
; Timeout to wait ESP response
DEFAULT_TIMEOUT EQU 2000
DEFDEVICE SPRINTER, 0x4000, 256, 0,1,2,3
SLDOPT COMMENT WPMEM, LOGPOINT, ASSERTION
DEVICE SPRINTER ;NOSLOT64K
IF DEBUG == 1
INCLUDE "dss.asm"
DB 0
ALIGN 16384, 0
DS 0x80, 0
ENDIF
INCLUDE "macro.inc"
INCLUDE "dss.inc"
;INCLUDE "sprinter.inc"
MODULE MAIN
ORG 0x8080
; ------------------------------------------------------
EXE_HEADER
DB "EXE"
DB EXE_VERSION ; EXE Version
DW 0x0080 ; Code offset
DW 0
DW 0 ; Primary loader size
DW 0 ; Reserved
DW 0
DW 0
DW START ; Loading Address
DW START ; Entry Point
DW STACK_TOP ; Stack address
DS 106, 0 ; Reserved
ORG 0x8100
@STACK_TOP
; ------------------------------------------------------
START
IF DEBUG == 1
LD IX,CMD_LINE_TFTP_D
LD SP, STACK_TOP
JP MAIN_LOOP
ENDIF
CALL PARSE_CMD_LINE
CALL OPEN_LOCAL_FILE
CALL ISA.ISA_RESET
CALL @WCOMMON.INIT_VMODE
PRINTLN MSG_START
CALL @WCOMMON.FIND_SWF
PRINTLN WCOMMON.MSG_UART_INIT
CALL @WIFI.UART_INIT
PRINTLN WCOMMON.MSG_ESP_RESET
CALL @WIFI.ESP_RESET
CALL @WCOMMON.INIT_ESP
PRINTLN MSG_HLP
CALL @WIFI.UART_EMPTY_RS
MAIN_LOOP
; ------------------------------------------------------
; Do Some
; ------------------------------------------------------
OK_EXIT
LD B,0
JP WCOMMON.EXIT
; ------------------------------------------------------
; IX - points to cmd line
; ------------------------------------------------------
PARSE_CMD_LINE
PUSH IX
POP HL
LD A,(HL)
OR A
JR Z, OUT_USAGE_MSG
CALL SKIP_SPACES
; check first parameter for tftp url pattern
LD DE,TFTF_START
CALL @UTIL.STARTSWITH
JR NZ,.PLC_UPLOAD
; Work Mode "Download"
; handle parameter URL
LD DE,0x0007
ADD HL,DE
CALL GET_SRV_PARAMS
CALL SKIP_SPACES
; handle lfn
CALL GET_LFN
RET
.PLC_UPLOAD
; Work mode "Upload"
LD A, WM_UPLOAD
LD (WORK_MODE),A
CALL GET_LFN
CALL SKIP_SPACES
CALL GET_SRV_PARAMS
RET
; ------------------------------------------------------
OUT_ERR_CMD_MSG
PRINTLN MSG_ERR_CMD
; ------------------------------------------------------
OUT_USAGE_MSG
PRINTLN MSG_HLP
JP OK_EXIT
; ------------------------------------------------------
; Move srv name and port number from (HL) to (DE)
; ------------------------------------------------------
GET_SRV_PARAMS
PUSH BC,DE
LD DE,SRV_NAME
.GSN_NEXT
LD A,(HL)
OR A ; end of url?
JR Z,.GSN_END
CP '/' ; end of server name?
JR Z,.GSN_END
CP ':' ; end of server name and has port?
JR Z,.GSN_PORT
LD (DE), A ; move and get next
INC HL
INC DE
JR .GSN_NEXT
; has port number
.GSN_PORT
LD DE,SRV_PORT
LD B,6
.GSNP_NXT
INC HL
LD A,(HL)
CP A,'/' ; end slash
JR .GSN_EN
CP A,'0'
JP M,.GSN_EPN
CP A,'9' ; >'9'?
JP P,.GSN_EPN
LD (DE),A
INC DE
DEC B
JR Z,.GSN_EPN ; too long number
JR .GSNP_NXT
; end of numbers
.GSN_EPN
PRINTLN MSG_ERR_PORT
JP OUT_USAGE_MSG
.GSN_EN
LD DE,SRV_PORT
LD A,(DE)
OR A ; ':/' - no port number specified
JR Z,.GSN_EPN
PUSH HL
CALL @UTIL.ATOU
LD (SRV_PORT),HL
POP HL
.GSN_END
; get file name from url
LD DE,REM_FILE
LD B,127
.GDNF_NXT
INC HL
LD A,(HL)
OR A
JR Z,.GDNF_END
LD (DE),A
INC DE
DEC B
JR NZ,.GDNF_NXT
JR .GDNF_ERR ; file name too long
; check file name is not empty
.GDNF_END
LD DE,REM_FILE
LD A,(DE)
OR A
JR NZ,.GSN_RET
; out error about invalid file name
.GDNF_ERR
PRINTLN MSG_ERR_RFN
JP OUT_USAGE_MSG
.GSN_RET
POP DE,BC
RET
; ------------------------------------------------------
; Get local file name from command string
;
; ------------------------------------------------------
GET_LFN
PUSH BC,DE
XOR B
LD DE,LOC_FILE
LD A,(HL)
OR A
JR Z,.GLF_E
CP ' '
JR Z,.GLF_E
; CP "\\"
; CALL Z,.GLF_SET_DIR
; CP ":"
; CALL Z,.GLF_SET_DIR
CP 0x21
JP M,.GLF_IFN
CP '*'
JP Z,.GLF_IFN
LD (DE),A
.GLF_E
POP DE,BC
RET
; set flag to not add current dir
.GLF_SET_DIR
LD B,1
RET
; Illegal file name
.GLF_IFN
PRINTLN MSG_ERR_LFN
JP OUT_USAGE_MSG
; ------------------------------------------------------
; Open local file for upload or download
; RO - for upload
; WR - for download
; ------------------------------------------------------
OPEN_LOCAL_FILE
LD A, (WORK_MODE)
CP WM_UPLOAD
RET
; ------------------------------------------------------
; Skip spaces at start of zero ended string
; Inp: HL - pointer to string
; Out: HL - points to first non space symbol
; ------------------------------------------------------
SKIP_SPACES
LD A, (HL)
OR A
RET Z
CP 0x21
RET P
INC HL
JR SKIP_SPACES
; ------------------------------------------------------
; Custom messages
; ------------------------------------------------------
MSG_START
DB "TFTP client for Sprinter-WiFi by Sprinter Team. v1.0 beta1, ", __DATE__, "\r\n"Z
MSG_ERR_CMD
DB "Invalid command line parameters!\r\n"Z
MSG_HLP
DB "\r\nUse: wtftp.exe tftp://server[:port]/filename filename - to download file from server;\r\n"
DB "\twtftp.exe filename tftp://server[:port]/filename - to upload file to server.\r\n"Z
MSG_TX_ERROR
DB "Transmitter not ready"Z
MSG_RX_ERROR
DB "Receiver error LSR: 0x"
MSG_LSR_VALUE
DB "xx"Z
MSG_MANY_RX_ERROR
DB "Too many receiver errors!"Z
MSG_ERR_PORT
DB "Invalid UDP port in URL, will be number 1..65535"Z
MSG_ERR_RFN
DB "Remote file name not specified in URL, or too long!"Z
MSG_ERR_LFN
DB "Invalid local file name!"Z
; Start of tftf URL
TFTF_START
DB "tftp://"Z
; Work Mode
WORK_MODE
DB WM_DOWNLOAD
; Name/IP of the tftp server
SRV_NAME
DS 128,0
; UDP port of the tftp server
SRV_PORT
DB 69,0,0,0,0,0 ; udp port number 0..65535
; Name of the source file
REM_FILE
DS 128,0
LOC_FILE
DS 128,0
LOC_FH
DW 0
; ------------------------------------------------------
; Custom commands
; ------------------------------------------------------
RX_ERR
DB 0
IF DEBUG == 1
CMD_TEST1 DB "ATE0\r\n"Z
BUFF_TEST1 DS RS_BUFF_SIZE,0
ENDIF
ENDMODULE
INCLUDE "wcommon.asm"
;INCLUDE "util.asm"
INCLUDE "isa.asm"
INCLUDE "esplib.asm"
END MAIN.START