diff --git a/sources/DSS/.vscode/launch.json b/sources/DSS/.vscode/launch.json index ba7da1c..31f946e 100644 --- a/sources/DSS/.vscode/launch.json +++ b/sources/DSS/.vscode/launch.json @@ -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" } ] diff --git a/sources/DSS/.vscode/tasks.json b/sources/DSS/.vscode/tasks.json index ba023e5..6b41c82 100644 --- a/sources/DSS/.vscode/tasks.json +++ b/sources/DSS/.vscode/tasks.json @@ -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", diff --git a/sources/DSS/dss.asm b/sources/DSS/dss.asm index c52c3a2..b8e2d17 100644 --- a/sources/DSS/dss.asm +++ b/sources/DSS/dss.asm @@ -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 \ No newline at end of file diff --git a/sources/DSS/dss.inc b/sources/DSS/dss.inc index 7a90f92..37bbc4f 100644 --- a/sources/DSS/dss.inc +++ b/sources/DSS/dss.inc @@ -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 diff --git a/sources/DSS/esplib.asm b/sources/DSS/esplib.asm index 8e7de6f..9b59974 100644 --- a/sources/DSS/esplib.asm +++ b/sources/DSS/esplib.asm @@ -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'? - LD HL, MSG_OK - CALL UTIL.STRCMP - JR NC, UTC_RET - ; It is 'ERROR'? - LD HL,MSG_ERROR - CALL UTIL.STRCMP - JR C, UTC_CP_FAIL - LD A, RES_ERROR - ; It is 'FAIL'? - JR UTC_RET + ; It is 'OK'? + LD HL, MSG_OK + CALL UTIL.STRCMP + JR NC, UTC_RET + ; It is 'ERROR'? + LD HL,MSG_ERROR + CALL UTIL.STRCMP + JR C, UTC_CP_FAIL + LD A, RES_ERROR + ; It is 'FAIL'? + 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 \ No newline at end of file diff --git a/sources/DSS/isa-test.asm b/sources/DSS/isa-test.asm index 44d7297..01b6a51 100644 --- a/sources/DSS/isa-test.asm +++ b/sources/DSS/isa-test.asm @@ -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 ; ------------------------------------------------------ diff --git a/sources/DSS/isa.asm b/sources/DSS/isa.asm index 2cb56a5..a788b03 100644 --- a/sources/DSS/isa.asm +++ b/sources/DSS/isa.asm @@ -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 \ No newline at end of file + ENDMODULE + + ENDIF \ No newline at end of file diff --git a/sources/DSS/macro.inc b/sources/DSS/macro.inc index 60412fc..c72f0ec 100644 --- a/sources/DSS/macro.inc +++ b/sources/DSS/macro.inc @@ -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 \ No newline at end of file + ENDM + + + ENDIF \ No newline at end of file diff --git a/sources/DSS/rfc/README.md b/sources/DSS/rfc/README.md new file mode 100644 index 0000000..260030b --- /dev/null +++ b/sources/DSS/rfc/README.md @@ -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 diff --git a/sources/DSS/rfc/rfc1350.txt b/sources/DSS/rfc/rfc1350.txt new file mode 100644 index 0000000..e00113b --- /dev/null +++ b/sources/DSS/rfc/rfc1350.txt @@ -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] + \ No newline at end of file diff --git a/sources/DSS/rfc/rfc2090.txt b/sources/DSS/rfc/rfc2090.txt new file mode 100644 index 0000000..dd2aeb7 --- /dev/null +++ b/sources/DSS/rfc/rfc2090.txt @@ -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] + diff --git a/sources/DSS/rfc/rfc2347.txt b/sources/DSS/rfc/rfc2347.txt new file mode 100644 index 0000000..dbc0f8c --- /dev/null +++ b/sources/DSS/rfc/rfc2347.txt @@ -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] + diff --git a/sources/DSS/rfc/rfc2348.txt b/sources/DSS/rfc/rfc2348.txt new file mode 100644 index 0000000..b38c56d --- /dev/null +++ b/sources/DSS/rfc/rfc2348.txt @@ -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] + diff --git a/sources/DSS/rfc/rfc2349.txt b/sources/DSS/rfc/rfc2349.txt new file mode 100644 index 0000000..31abb3e --- /dev/null +++ b/sources/DSS/rfc/rfc2349.txt @@ -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] + diff --git a/sources/DSS/rfc/rfc7440.txt b/sources/DSS/rfc/rfc7440.txt new file mode 100644 index 0000000..47badcf --- /dev/null +++ b/sources/DSS/rfc/rfc7440.txt @@ -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, + . + + [RFC2347] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC + 2347, May 1998, . + + [RFC2348] Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC + 2348, May 1998, . + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage + Guidelines for Application Designers", BCP 145, RFC 5405, + November 2008, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + +Author's Address + + Patrick Masotta + Serva + + EMail: patrick.masotta.ietf@vercot.com + URI: http://www.vercot.com/~serva/ + + + + + + + + + + + + + + + + + + + + + + +Masotta Standards Track [Page 9] + diff --git a/sources/DSS/sprinter.inc b/sources/DSS/sprinter.inc index 1a2037c..ee24514 100644 --- a/sources/DSS/sprinter.inc +++ b/sources/DSS/sprinter.inc @@ -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 \ No newline at end of file diff --git a/sources/DSS/util.asm b/sources/DSS/util.asm index 3c16254..6dcf3a2 100644 --- a/sources/DSS/util.asm +++ b/sources/DSS/util.asm @@ -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 \ No newline at end of file + ENDMODULE + + ENDIF \ No newline at end of file diff --git a/sources/DSS/wcommon.asm b/sources/DSS/wcommon.asm index d39cd75..028a3ab 100644 --- a/sources/DSS/wcommon.asm +++ b/sources/DSS/wcommon.asm @@ -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 diff --git a/sources/DSS/wterm.asm b/sources/DSS/wterm.asm index 9a76c66..dea188f 100644 --- a/sources/DSS/wterm.asm +++ b/sources/DSS/wterm.asm @@ -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 , , [, [, ...]] 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" diff --git a/sources/DSS/wtftp.asm b/sources/DSS/wtftp.asm new file mode 100644 index 0000000..0d0f0ea --- /dev/null +++ b/sources/DSS/wtftp.asm @@ -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