mirror of
https://github.com/romychs/ESPKit.git
synced 2025-12-19 15:23:19 +03:00
WFTP First impl
This commit is contained in:
boykovra
parent
2d74d03448
commit
69deb4907a
86
sources/DSS/.vscode/launch.json
vendored
86
sources/DSS/.vscode/launch.json
vendored
@ -155,7 +155,7 @@
|
|||||||
"codeCoverageEnabled": true
|
"codeCoverageEnabled": true
|
||||||
},
|
},
|
||||||
"startAutomatically": false,
|
"startAutomatically": false,
|
||||||
"commandsAfterLaunch": [],
|
"commandsAfterLaunch": ["-rmv"],
|
||||||
"rootFolder": "${workspaceFolder}",
|
"rootFolder": "${workspaceFolder}",
|
||||||
"topOfStack": "STACK_TOP",
|
"topOfStack": "STACK_TOP",
|
||||||
"loadObjs": [
|
"loadObjs": [
|
||||||
@ -167,6 +167,90 @@
|
|||||||
"execAddress": "0x8100",
|
"execAddress": "0x8100",
|
||||||
"smallValuesMaximum": 513,
|
"smallValuesMaximum": 513,
|
||||||
"tmpDir": ".tmp"
|
"tmpDir": ".tmp"
|
||||||
|
},
|
||||||
|
|
||||||
|
{
|
||||||
|
"type": "dezog",
|
||||||
|
"request": "launch",
|
||||||
|
"name": "WTFTP Internal Simulator",
|
||||||
|
"remoteType": "zsim",
|
||||||
|
"zsim": {
|
||||||
|
"visualMemory": true,
|
||||||
|
"memoryModel": "CUSTOM",
|
||||||
|
"customMemory": {
|
||||||
|
"slots": [
|
||||||
|
{
|
||||||
|
"name": "PAGE0",
|
||||||
|
"range": ["0x0000","0x3FFF"],
|
||||||
|
"banks": [{"index": [0, 255]}],
|
||||||
|
"initialBank": 0
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "PAGE1",
|
||||||
|
"range": ["0x4000","0x7FFF"],
|
||||||
|
"banks": [{"index": [0, 255]}],
|
||||||
|
"initialBank": 1
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "PAGE2",
|
||||||
|
"range": ["0x8000","0xBFFF"],
|
||||||
|
"banks": [{"index": [0, 255]}],
|
||||||
|
"initialBank": 2
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "PAGE3",
|
||||||
|
"range": ["0xC000","0xFFFF"],
|
||||||
|
"banks": [{"index": [0, 255]}],
|
||||||
|
"initialBank": 3
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"ioMmu": [
|
||||||
|
"if (portAddress == 0x82) {",
|
||||||
|
" bank = portValue;",
|
||||||
|
" PAGE0 = bank;",
|
||||||
|
"}",
|
||||||
|
"if (portAddress == 0xA2) {",
|
||||||
|
" bank = portValue;",
|
||||||
|
" PAGE1 = bank;",
|
||||||
|
"}",
|
||||||
|
"if (portAddress == 0xC2) {",
|
||||||
|
" bank = portValue;",
|
||||||
|
" PAGE2 = bank;",
|
||||||
|
"}",
|
||||||
|
"if (portAddress == 0xE2) {",
|
||||||
|
" bank = portValue;",
|
||||||
|
" PAGE3 = bank;",
|
||||||
|
"}"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"customCode": {
|
||||||
|
"debug": false,
|
||||||
|
"jsPath": "sim/ports.js"
|
||||||
|
},
|
||||||
|
},
|
||||||
|
"sjasmplus": [
|
||||||
|
{
|
||||||
|
"path": "wtftp.sld"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"history": {
|
||||||
|
"reverseDebugInstructionCount": 1000000,
|
||||||
|
"spotCount": 10,
|
||||||
|
"codeCoverageEnabled": true
|
||||||
|
},
|
||||||
|
"startAutomatically": false,
|
||||||
|
"commandsAfterLaunch": ["-rmv"],
|
||||||
|
"rootFolder": "${workspaceFolder}",
|
||||||
|
"topOfStack": "STACK_TOP",
|
||||||
|
"loadObjs": [
|
||||||
|
{
|
||||||
|
"path": "wtftp.exe",
|
||||||
|
"start": "0x0000"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"execAddress": "0x8100",
|
||||||
|
"smallValuesMaximum": 513,
|
||||||
|
"tmpDir": ".tmp"
|
||||||
}
|
}
|
||||||
|
|
||||||
]
|
]
|
||||||
|
|||||||
59
sources/DSS/.vscode/tasks.json
vendored
59
sources/DSS/.vscode/tasks.json
vendored
@ -53,7 +53,7 @@
|
|||||||
},
|
},
|
||||||
"group": {
|
"group": {
|
||||||
"kind": "build",
|
"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",
|
"label": "start mame",
|
||||||
"type": "shell",
|
"type": "shell",
|
||||||
|
|||||||
@ -169,7 +169,7 @@ _CLOSE_FILE
|
|||||||
JP NORM_EXIT
|
JP NORM_EXIT
|
||||||
|
|
||||||
CUR_F_PTR
|
CUR_F_PTR
|
||||||
DW ZIP_FILE
|
DW IN_FILE
|
||||||
|
|
||||||
REMAINS_IN_ZIP
|
REMAINS_IN_ZIP
|
||||||
DW 0
|
DW 0
|
||||||
@ -192,7 +192,7 @@ _READ_FILE
|
|||||||
PUSH HL
|
PUSH HL
|
||||||
|
|
||||||
LD HL, (CUR_F_PTR) ; HL -> IN ZIP_FILE
|
LD HL, (CUR_F_PTR) ; HL -> IN ZIP_FILE
|
||||||
LD DE, ZIP_FILE_END
|
LD DE, IN_FILE_END
|
||||||
EX HL, DE
|
EX HL, DE
|
||||||
SUB HL, DE ; HL = remain bytes
|
SUB HL, DE ; HL = remain bytes
|
||||||
LD (REMAINS_IN_ZIP), HL
|
LD (REMAINS_IN_ZIP), HL
|
||||||
@ -225,7 +225,7 @@ _WRITE_FILE
|
|||||||
|
|
||||||
PUSH DE
|
PUSH DE
|
||||||
POP BC
|
POP BC
|
||||||
LD DE,UNZIP_FILE
|
LD DE,OUT_FILE
|
||||||
|
|
||||||
PUSH BC
|
PUSH BC
|
||||||
LDIR
|
LDIR
|
||||||
@ -279,7 +279,7 @@ _FIND_FIRST
|
|||||||
LD HL, 33 ; offset of file name
|
LD HL, 33 ; offset of file name
|
||||||
ADD HL, DE
|
ADD HL, DE
|
||||||
EX HL, DE
|
EX HL, DE
|
||||||
LD HL, ZIP_FILE_NAME
|
LD HL, IN_FILE_NAME
|
||||||
LD BC,9
|
LD BC,9
|
||||||
LDIR
|
LDIR
|
||||||
POP DE
|
POP DE
|
||||||
@ -360,13 +360,15 @@ _EXIT
|
|||||||
HALT
|
HALT
|
||||||
JP _EXIT
|
JP _EXIT
|
||||||
|
|
||||||
|
CMD_LINE_TFTP_D
|
||||||
|
DB " tftp://tftp.server.ru:1024/file_in.asm c:\\tmp\\file_out.asm"Z
|
||||||
|
|
||||||
ZIP_FILE_NAME
|
IN_FILE
|
||||||
DB "file.zip",0
|
|
||||||
ZIP_FILE
|
|
||||||
DS 1024,0
|
DS 1024,0
|
||||||
ZIP_FILE_END
|
IN_FILE_END
|
||||||
UNZIP_FILE
|
IN_FILE_NAME
|
||||||
|
DB "infile.txt"
|
||||||
|
OUT_FILE
|
||||||
DS 1024,0
|
DS 1024,0
|
||||||
|
|
||||||
ALIGN 16384, 0
|
ALIGN 16384, 0
|
||||||
@ -4,6 +4,9 @@
|
|||||||
; https://github.com/romychs
|
; https://github.com/romychs
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
IFNDEF _DSS_INC
|
||||||
|
DEFINE _DSS_INC
|
||||||
|
|
||||||
; DSS RST Entry
|
; DSS RST Entry
|
||||||
DSS EQU 0x10
|
DSS EQU 0x10
|
||||||
|
|
||||||
@ -55,3 +58,12 @@ KB_R_SHIFT EQU 0x40
|
|||||||
KB_L_SHIFT EQU 0x80
|
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
|
||||||
|
|||||||
@ -5,6 +5,10 @@
|
|||||||
; License: BSD 3-Clause
|
; License: BSD 3-Clause
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
|
||||||
|
INCLUDE "isa.asm"
|
||||||
|
INCLUDE "util.asm"
|
||||||
|
|
||||||
;ISA_BASE_A EQU 0xC000 ; Базовый адрес портов ISA в памяти
|
;ISA_BASE_A EQU 0xC000 ; Базовый адрес портов ISA в памяти
|
||||||
PORT_UART EQU 0x03E8 ; Базовый номер порта COM3
|
PORT_UART EQU 0x03E8 ; Базовый номер порта COM3
|
||||||
PORT_UART_A EQU ISA_BASE_A + PORT_UART ; Порты чипа UART в памяти
|
PORT_UART_A EQU ISA_BASE_A + PORT_UART ; Порты чипа UART в памяти
|
||||||
@ -101,6 +105,7 @@ _AFR EQU 2
|
|||||||
; Find TL550C in ISA slot
|
; Find TL550C in ISA slot
|
||||||
; Out: CF=1 - Not found, CF=0 - ISA.ISA_SLOT found in slot
|
; Out: CF=1 - Not found, CF=0 - ISA.ISA_SLOT found in slot
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_FIND
|
||||||
UART_FIND
|
UART_FIND
|
||||||
PUSH HL
|
PUSH HL
|
||||||
XOR A
|
XOR A
|
||||||
@ -113,7 +118,6 @@ UART_FIND
|
|||||||
UF_T_FND
|
UF_T_FND
|
||||||
POP HL
|
POP HL
|
||||||
RET
|
RET
|
||||||
|
|
||||||
; Test slot, A - ISA Slot no. 0 or 1
|
; Test slot, A - ISA Slot no. 0 or 1
|
||||||
UT_T_SLOT
|
UT_T_SLOT
|
||||||
; check IER hi bits, will be 0
|
; check IER hi bits, will be 0
|
||||||
@ -137,12 +141,12 @@ CHK_SCR
|
|||||||
CALL UART_READ
|
CALL UART_READ
|
||||||
CP D
|
CP D
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Init UART device TL16C550
|
; Init UART device TL16C550
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_INIT
|
||||||
UART_INIT
|
UART_INIT
|
||||||
PUSH AF, IX
|
PUSH AF, IX
|
||||||
|
|
||||||
@ -166,41 +170,47 @@ UART_INIT
|
|||||||
|
|
||||||
POP IX,AF
|
POP IX,AF
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Read TL16C550 register
|
; Read TL16C550 register
|
||||||
; Inp: HL - register
|
; Inp: HL - register
|
||||||
; Out: A - value from register
|
; Out: A - value from register
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_READ
|
||||||
UART_READ
|
UART_READ
|
||||||
CALL ISA.ISA_OPEN
|
CALL ISA.ISA_OPEN
|
||||||
LD A, (HL)
|
LD A, (HL)
|
||||||
CALL ISA.ISA_CLOSE
|
CALL ISA.ISA_CLOSE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Write TL16C550 register
|
; Write TL16C550 register
|
||||||
; Inp: HL - register, E - value
|
; Inp: HL - register, E - value
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_WRITE
|
||||||
UART_WRITE
|
UART_WRITE
|
||||||
CALL ISA.ISA_OPEN
|
CALL ISA.ISA_OPEN
|
||||||
LD (HL), E
|
LD (HL), E
|
||||||
CALL ISA.ISA_CLOSE
|
CALL ISA.ISA_CLOSE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Wait for transmitter ready
|
; Wait for transmitter ready
|
||||||
; Out: CF=1 - tr not ready, CF=0 ready
|
; Out: CF=1 - tr not ready, CF=0 ready
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_WAIT_TR
|
||||||
UART_WAIT_TR
|
UART_WAIT_TR
|
||||||
CALL ISA.ISA_OPEN
|
CALL ISA.ISA_OPEN
|
||||||
CALL UART_WAIT_TR_INT
|
CALL UART_WAIT_TR_INT
|
||||||
CALL ISA.ISA_CLOSE
|
CALL ISA.ISA_CLOSE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
;
|
;
|
||||||
; Wait, without open/close ISA
|
; Wait, without open/close ISA
|
||||||
;
|
;
|
||||||
|
;IFUSED UART_WAIT_TR_INT
|
||||||
|
|
||||||
UART_WAIT_TR_INT
|
UART_WAIT_TR_INT
|
||||||
PUSH BC, HL, DE
|
PUSH BC, HL, DE
|
||||||
LD D,A
|
LD D,A
|
||||||
@ -210,7 +220,7 @@ WAIT_TR_BZY
|
|||||||
LD A,(HL)
|
LD A,(HL)
|
||||||
AND A, LSR_THRE
|
AND A, LSR_THRE
|
||||||
JR NZ,WAIT_TR_RDY
|
JR NZ,WAIT_TR_RDY
|
||||||
CALL UTIL.DELAY_100uS ; ~11 bit tx delay
|
CALL @UTIL.DELAY_100uS ; ~11 bit tx delay
|
||||||
DEC BC
|
DEC BC
|
||||||
LD A, C
|
LD A, C
|
||||||
OR B
|
OR B
|
||||||
@ -220,12 +230,14 @@ WAIT_TR_RDY
|
|||||||
LD A,D
|
LD A,D
|
||||||
POP DE, HL, BC
|
POP DE, HL, BC
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Transmit byte
|
; Transmit byte
|
||||||
; Inp: E - byte
|
; Inp: E - byte
|
||||||
; Out: CF=1 - Not ready
|
; Out: CF=1 - Not ready
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_TX_BYTE
|
||||||
UART_TX_BYTE
|
UART_TX_BYTE
|
||||||
PUSH DE
|
PUSH DE
|
||||||
CALL UART_WAIT_TR
|
CALL UART_WAIT_TR
|
||||||
@ -236,12 +248,13 @@ UART_TX_BYTE
|
|||||||
UTB_NOT_R
|
UTB_NOT_R
|
||||||
POP DE
|
POP DE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Transmit buffer
|
; Transmit buffer
|
||||||
; Inp: HL -> buffer, BC - size
|
; Inp: HL -> buffer, BC - size
|
||||||
; Out: CF=0 - Ok, CF=1 - Timeout
|
; Out: CF=0 - Ok, CF=1 - Timeout
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_TX_BUFFER
|
||||||
UART_TX_BUFFER
|
UART_TX_BUFFER
|
||||||
PUSH BC,DE,HL
|
PUSH BC,DE,HL
|
||||||
LD DE, REG_THR
|
LD DE, REG_THR
|
||||||
@ -267,12 +280,14 @@ UTX_TXNR
|
|||||||
CALL ISA.ISA_CLOSE
|
CALL ISA.ISA_CLOSE
|
||||||
POP HL,DE,BC
|
POP HL,DE,BC
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Transmit zero ended string
|
; Transmit zero ended string
|
||||||
; Inp: HL -> buffer
|
; Inp: HL -> buffer
|
||||||
; Out: CF=0 - Ok, CF=1 - Timeout
|
; Out: CF=0 - Ok, CF=1 - Timeout
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_TX_STRING
|
||||||
UART_TX_STRING
|
UART_TX_STRING
|
||||||
PUSH DE,HL
|
PUSH DE,HL
|
||||||
LD DE, REG_THR
|
LD DE, REG_THR
|
||||||
@ -296,13 +311,12 @@ UTXS_TXNR
|
|||||||
CALL ISA.ISA_CLOSE
|
CALL ISA.ISA_CLOSE
|
||||||
POP HL,DE
|
POP HL,DE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Empty receiver FIFO buffer
|
; Empty receiver FIFO buffer
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_EMPTY_RS
|
||||||
UART_EMPTY_RS
|
UART_EMPTY_RS
|
||||||
PUSH DE, HL
|
PUSH DE, HL
|
||||||
LD E, FCR_TR8 | FCR_RESET_RX | FCR_FIFO
|
LD E, FCR_TR8 | FCR_RESET_RX | FCR_FIFO
|
||||||
@ -310,6 +324,7 @@ UART_EMPTY_RS
|
|||||||
CALL UART_WRITE
|
CALL UART_WRITE
|
||||||
POP HL, DE
|
POP HL, DE
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Wait byte in receiver fifo
|
; Wait byte in receiver fifo
|
||||||
@ -333,7 +348,7 @@ UVR_NEXT
|
|||||||
OR C
|
OR C
|
||||||
JR NZ,UVR_NEXT
|
JR NZ,UVR_NEXT
|
||||||
UVR_TO
|
UVR_TO
|
||||||
IF TRACE
|
IFDEF TRACE
|
||||||
PUSH AF,BC,DE,HL
|
PUSH AF,BC,DE,HL
|
||||||
PRINTLN MSG_RCV_EMPTY
|
PRINTLN MSG_RCV_EMPTY
|
||||||
POP HL,DE,BC,AF
|
POP HL,DE,BC,AF
|
||||||
@ -346,6 +361,7 @@ UVR_OK
|
|||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Reset ESP module
|
; Reset ESP module
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED ESP_RESET
|
||||||
ESP_RESET
|
ESP_RESET
|
||||||
PUSH AF,HL
|
PUSH AF,HL
|
||||||
|
|
||||||
@ -365,17 +381,7 @@ ESP_RESET
|
|||||||
|
|
||||||
POP HL,AF
|
POP HL,AF
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
; 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
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; UART TX Command
|
; UART TX Command
|
||||||
@ -384,104 +390,122 @@ MSG_FAIL DB "FAIL", 0
|
|||||||
; BC - wait ms
|
; BC - wait ms
|
||||||
; Out: CF=1 if Error
|
; Out: CF=1 if Error
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
;IFUSED UART_TX_CMD
|
||||||
UART_TX_CMD
|
UART_TX_CMD
|
||||||
PUSH BC, DE, HL
|
PUSH BC, DE, HL
|
||||||
|
|
||||||
LD A, low RS_BUFF_SIZE
|
LD A, low RS_BUFF_SIZE
|
||||||
LD (BSIZE), A
|
LD (BSIZE), A
|
||||||
LD A, high RS_BUFF_SIZE
|
LD A, high RS_BUFF_SIZE
|
||||||
LD (BSIZE+1), A
|
LD (BSIZE+1), A
|
||||||
|
|
||||||
;LD (RESBUF),DE
|
;LD (RESBUF),DE
|
||||||
XOR A
|
XOR A
|
||||||
LD (DE), A
|
LD (DE), A
|
||||||
|
|
||||||
LD (WAIT_MS), BC
|
LD (WAIT_MS), BC
|
||||||
CALL UART_EMPTY_RS
|
CALL UART_EMPTY_RS
|
||||||
|
|
||||||
; HL - Buffer, BC - Size
|
; HL - Buffer, BC - Size
|
||||||
;CALL UTIL.STRLEN
|
;CALL UTIL.STRLEN
|
||||||
CALL UART_TX_STRING
|
CALL UART_TX_STRING
|
||||||
JR NC, UTC_STRT_RX
|
JR NC, UTC_STRT_RX
|
||||||
; error, transmit timeout
|
; error, transmit timeout
|
||||||
LD A, RES_TX_TIMEOUT
|
LD A, RES_TX_TIMEOUT
|
||||||
JR UTC_RET
|
JR UTC_RET
|
||||||
UTC_STRT_RX
|
UTC_STRT_RX
|
||||||
; no transmit timeout, receive response
|
; no transmit timeout, receive response
|
||||||
; IX - pointer to begin of current line
|
; IX - pointer to begin of current line
|
||||||
LD IXH, D
|
LD IXH, D
|
||||||
LD IXL, E
|
LD IXL, E
|
||||||
LD BC,(BSIZE)
|
LD BC,(BSIZE)
|
||||||
UTC_RCV_NXT
|
UTC_RCV_NXT
|
||||||
; wait receiver ready
|
; wait receiver ready
|
||||||
;LD BC,(WAIT_MS)
|
;LD BC,(WAIT_MS)
|
||||||
CALL UART_WAIT_RS1
|
CALL UART_WAIT_RS1
|
||||||
JR NC, UTC_NO_RT
|
JR NC, UTC_NO_RT
|
||||||
; error, read timeout
|
; error, read timeout
|
||||||
LD A, RES_RS_TIMEOUT
|
LD A, RES_RS_TIMEOUT
|
||||||
JR UTC_RET
|
JR UTC_RET
|
||||||
; no receive timeout
|
; no receive timeout
|
||||||
UTC_NO_RT
|
UTC_NO_RT
|
||||||
|
; read symbol from tty
|
||||||
; read symbol from tty
|
LD HL, REG_RBR
|
||||||
LD HL, REG_RBR
|
CALL UART_READ
|
||||||
CALL UART_READ
|
CP CR
|
||||||
CP CR
|
JP Z, UTC_RCV_NXT ; Skip CR
|
||||||
JP Z, UTC_RCV_NXT ; Skip CR
|
CP LF
|
||||||
CP LF
|
JR Z, UTC_END ; LF - last symbol in responce
|
||||||
JR Z, UTC_END ; LF - last symbol in responce
|
LD (DE),A
|
||||||
LD (DE),A
|
INC DE
|
||||||
INC DE
|
DEC BC
|
||||||
DEC BC
|
LD A, B
|
||||||
LD A, B
|
OR C
|
||||||
OR C
|
JR NZ, UTC_RCV_NXT
|
||||||
JR NZ, UTC_RCV_NXT
|
|
||||||
|
|
||||||
UTC_END
|
UTC_END
|
||||||
XOR A
|
XOR A
|
||||||
LD (DE),A ; temporary mark end of string
|
LD (DE),A ; temporary mark end of string
|
||||||
PUSH DE ; store DE
|
PUSH DE ; store DE
|
||||||
POP IY
|
POP IY
|
||||||
PUSH IX
|
PUSH IX
|
||||||
POP DE ; DE - ptr to begin pf current line
|
POP DE ; DE - ptr to begin pf current line
|
||||||
|
|
||||||
; It is 'OK<LF>'?
|
; It is 'OK<LF>'?
|
||||||
LD HL, MSG_OK
|
LD HL, MSG_OK
|
||||||
CALL UTIL.STRCMP
|
CALL UTIL.STRCMP
|
||||||
JR NC, UTC_RET
|
JR NC, UTC_RET
|
||||||
; It is 'ERROR<LF>'?
|
; It is 'ERROR<LF>'?
|
||||||
LD HL,MSG_ERROR
|
LD HL,MSG_ERROR
|
||||||
CALL UTIL.STRCMP
|
CALL UTIL.STRCMP
|
||||||
JR C, UTC_CP_FAIL
|
JR C, UTC_CP_FAIL
|
||||||
LD A, RES_ERROR
|
LD A, RES_ERROR
|
||||||
; It is 'FAIL<LF>'?
|
; It is 'FAIL<LF>'?
|
||||||
JR UTC_RET
|
JR UTC_RET
|
||||||
UTC_CP_FAIL
|
UTC_CP_FAIL
|
||||||
LD HL,MSG_FAIL
|
LD HL,MSG_FAIL
|
||||||
CALL UTIL.STRCMP
|
CALL @UTIL.STRCMP
|
||||||
JR C, UTC_NOMSG
|
JR C, UTC_NOMSG
|
||||||
LD A, RES_FAIL
|
LD A, RES_FAIL
|
||||||
JR UTC_RET
|
JR UTC_RET
|
||||||
UTC_NOMSG
|
UTC_NOMSG
|
||||||
; no resp message, continue receive
|
; no resp message, continue receive
|
||||||
PUSH IY
|
PUSH IY
|
||||||
POP DE
|
POP DE
|
||||||
LD A, LF
|
LD A, LF
|
||||||
LD (DE),A ; change 0 - EOL to LF
|
LD (DE),A ; change 0 - EOL to LF
|
||||||
INC DE
|
INC DE
|
||||||
LD IXH,D ; store new start line ptr
|
LD IXH,D ; store new start line ptr
|
||||||
LD IXL,E
|
LD IXL,E
|
||||||
JR UTC_RCV_NXT
|
JR UTC_RCV_NXT
|
||||||
UTC_RET
|
UTC_RET
|
||||||
POP HL, DE, BC
|
POP HL, DE, BC
|
||||||
RET
|
RET
|
||||||
|
;ENDIF
|
||||||
|
|
||||||
IF TRACE
|
IFDEF TRACE
|
||||||
MSG_RCV_EMPTY
|
MSG_RCV_EMPTY
|
||||||
DB "Receiver is empty!",0
|
DB "Receiver is empty!",0
|
||||||
ENDIF
|
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
|
; Buffer to receive response from ESP
|
||||||
RS_BUFF DS RS_BUFF_SIZE, 0
|
RS_BUFF DS RS_BUFF_SIZE, 0
|
||||||
|
ENDIF
|
||||||
|
|
||||||
ENDMODULE
|
ENDMODULE
|
||||||
@ -57,6 +57,7 @@ START
|
|||||||
JP MAIN_LOOP
|
JP MAIN_LOOP
|
||||||
ENDIF
|
ENDIF
|
||||||
|
|
||||||
|
CALL @WCOMMON.INIT_VMODE
|
||||||
|
|
||||||
PRINTLN MSG_START
|
PRINTLN MSG_START
|
||||||
|
|
||||||
@ -79,12 +80,28 @@ START
|
|||||||
; INC D
|
; INC D
|
||||||
|
|
||||||
CALL ISA.ISA_OPEN
|
CALL ISA.ISA_OPEN
|
||||||
LD HL, PORT_UART_A
|
|
||||||
|
LD HL, REG_SCR
|
||||||
LD D,0x55
|
LD D,0x55
|
||||||
L_AGAIN
|
|
||||||
.1000 LD (HL), D
|
LD BC, PORT_ISA
|
||||||
.1000 LD D,(HL)
|
LD A, ISA_AEN ; AEN=1 (for sync LA by front)
|
||||||
JP L_AGAIN
|
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 --------------
|
; --------- RESET & AEN --------------
|
||||||
; LD BC, PORT_ISA
|
; LD BC, PORT_ISA
|
||||||
@ -108,7 +125,7 @@ MAIN_LOOP
|
|||||||
|
|
||||||
OK_EXIT
|
OK_EXIT
|
||||||
LD B,0
|
LD B,0
|
||||||
JP WCOMMON.EXIT
|
JP @WCOMMON.EXIT
|
||||||
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
|||||||
@ -5,6 +5,12 @@
|
|||||||
; License: BSD 3-Clause
|
; License: BSD 3-Clause
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
IFNDEF _ISA_ASM
|
||||||
|
DEFINE _ISA_ASM
|
||||||
|
|
||||||
|
INCLUDE "sprinter.inc"
|
||||||
|
INCLUDE "util.asm"
|
||||||
|
|
||||||
PORT_ISA EQU 0x9FBD
|
PORT_ISA EQU 0x9FBD
|
||||||
PORT_SYSTEM EQU 0x1FFD
|
PORT_SYSTEM EQU 0x1FFD
|
||||||
|
|
||||||
@ -29,11 +35,11 @@ ISA_RESET
|
|||||||
LD BC, PORT_ISA
|
LD BC, PORT_ISA
|
||||||
LD A,ISA_RST | ISA_AEN ; RESET=1 AEN=1
|
LD A,ISA_RST | ISA_AEN ; RESET=1 AEN=1
|
||||||
OUT (C), A
|
OUT (C), A
|
||||||
CALL UTIL.DELAY_1MS
|
CALL @UTIL.DELAY_1MS
|
||||||
XOR A
|
XOR A
|
||||||
OUT (C), A ; RESET=0 AEN=0
|
OUT (C), A ; RESET=0 AEN=0
|
||||||
LD HL,100
|
LD HL,100
|
||||||
CALL UTIL.DELAY
|
CALL @UTIL.DELAY
|
||||||
RET
|
RET
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
@ -78,3 +84,5 @@ ISA_CLOSE
|
|||||||
SAVE_MMU3 DB 0
|
SAVE_MMU3 DB 0
|
||||||
|
|
||||||
ENDMODULE
|
ENDMODULE
|
||||||
|
|
||||||
|
ENDIF
|
||||||
@ -5,10 +5,13 @@
|
|||||||
; License: BSD 3-Clause
|
; License: BSD 3-Clause
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
IFNDEF _MACRO
|
||||||
|
DEFINE _MACRO
|
||||||
|
|
||||||
; Transmit data|command via UART and check response
|
; Transmit data|command via UART and check response
|
||||||
MACRO SEND_CMD data
|
MACRO SEND_CMD data
|
||||||
LD HL, data
|
LD HL, data
|
||||||
CALL WIFI.UART_TX_CMD
|
CALL @WIFI.UART_TX_CMD
|
||||||
CALL CHECK_ERROR
|
CALL CHECK_ERROR
|
||||||
ENDM
|
ENDM
|
||||||
|
|
||||||
@ -47,3 +50,6 @@
|
|||||||
ENDIF
|
ENDIF
|
||||||
RST DSS
|
RST DSS
|
||||||
ENDM
|
ENDM
|
||||||
|
|
||||||
|
|
||||||
|
ENDIF
|
||||||
14
sources/DSS/rfc/README.md
Normal file
14
sources/DSS/rfc/README.md
Normal file
@ -0,0 +1,14 @@
|
|||||||
|
# TFTP Specifications
|
||||||
|
|
||||||
|
## Current RFC
|
||||||
|
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
|
||||||
|
RFC2090 - TFTP Multicast Option
|
||||||
|
RFC2347 - TFTP Option Extension
|
||||||
|
RFC2348 - TFTP Blocksize Option
|
||||||
|
RFC2349 - TFTP Timeout Interval and Transfer Size Options
|
||||||
|
RFC7440 - TFTP Windowsize Option
|
||||||
|
|
||||||
|
## Obsolete RFC
|
||||||
|
RFC1782 - TFTP Option Extension
|
||||||
|
RFC1783 - TFTP Blocksize Option
|
||||||
|
RFC1784 - TFTP Timeout Interval and Transfer Size Options
|
||||||
619
sources/DSS/rfc/rfc1350.txt
Normal file
619
sources/DSS/rfc/rfc1350.txt
Normal file
@ -0,0 +1,619 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group K. Sollins
|
||||||
|
Request For Comments: 1350 MIT
|
||||||
|
STD: 33 July 1992
|
||||||
|
Obsoletes: RFC 783
|
||||||
|
|
||||||
|
|
||||||
|
THE TFTP PROTOCOL (REVISION 2)
|
||||||
|
|
||||||
|
Status of this Memo
|
||||||
|
|
||||||
|
This RFC specifies an IAB standards track protocol for the Internet
|
||||||
|
community, and requests discussion and suggestions for improvements.
|
||||||
|
Please refer to the current edition of the "IAB Official Protocol
|
||||||
|
Standards" for the standardization state and status of this protocol.
|
||||||
|
Distribution of this memo is unlimited.
|
||||||
|
|
||||||
|
Summary
|
||||||
|
|
||||||
|
TFTP is a very simple protocol used to transfer files. It is from
|
||||||
|
this that its name comes, Trivial File Transfer Protocol or TFTP.
|
||||||
|
Each nonterminal packet is acknowledged separately. This document
|
||||||
|
describes the protocol and its types of packets. The document also
|
||||||
|
explains the reasons behind some of the design decisions.
|
||||||
|
|
||||||
|
Acknowlegements
|
||||||
|
|
||||||
|
The protocol was originally designed by Noel Chiappa, and was
|
||||||
|
redesigned by him, Bob Baldwin and Dave Clark, with comments from
|
||||||
|
Steve Szymanski. The current revision of the document includes
|
||||||
|
modifications stemming from discussions with and suggestions from
|
||||||
|
Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
|
||||||
|
Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
|
||||||
|
Yellick, and the author. The acknowledgement and retransmission
|
||||||
|
scheme was inspired by TCP, and the error mechanism was suggested by
|
||||||
|
PARC's EFTP abort message.
|
||||||
|
|
||||||
|
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
|
||||||
|
bug [4] and other minor document problems was done by Noel Chiappa.
|
||||||
|
|
||||||
|
This research was supported by the Advanced Research Projects Agency
|
||||||
|
of the Department of Defense and was monitored by the Office of Naval
|
||||||
|
Research under contract number N00014-75-C-0661.
|
||||||
|
|
||||||
|
1. Purpose
|
||||||
|
|
||||||
|
TFTP is a simple protocol to transfer files, and therefore was named
|
||||||
|
the Trivial File Transfer Protocol or TFTP. It has been implemented
|
||||||
|
on top of the Internet User Datagram protocol (UDP or Datagram) [2]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 1]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
so it may be used to move files between machines on different
|
||||||
|
networks implementing UDP. (This should not exclude the possibility
|
||||||
|
of implementing TFTP on top of other datagram protocols.) It is
|
||||||
|
designed to be small and easy to implement. Therefore, it lacks most
|
||||||
|
of the features of a regular FTP. The only thing it can do is read
|
||||||
|
and write files (or mail) from/to a remote server. It cannot list
|
||||||
|
directories, and currently has no provisions for user authentication.
|
||||||
|
In common with other Internet protocols, it passes 8 bit bytes of
|
||||||
|
data.
|
||||||
|
|
||||||
|
Three modes of transfer are currently supported: netascii (This is
|
||||||
|
ascii as defined in "USA Standard Code for Information Interchange"
|
||||||
|
[1] with the modifications specified in "Telnet Protocol
|
||||||
|
Specification" [3].) Note that it is 8 bit ascii. The term
|
||||||
|
"netascii" will be used throughout this document to mean this
|
||||||
|
particular version of ascii.); octet (This replaces the "binary" mode
|
||||||
|
of previous versions of this document.) raw 8 bit bytes; mail,
|
||||||
|
netascii characters sent to a user rather than a file. (The mail
|
||||||
|
mode is obsolete and should not be implemented or used.) Additional
|
||||||
|
modes can be defined by pairs of cooperating hosts.
|
||||||
|
|
||||||
|
Reference [4] (section 4.2) should be consulted for further valuable
|
||||||
|
directives and suggestions on TFTP.
|
||||||
|
|
||||||
|
2. Overview of the Protocol
|
||||||
|
|
||||||
|
Any transfer begins with a request to read or write a file, which
|
||||||
|
also serves to request a connection. If the server grants the
|
||||||
|
request, the connection is opened and the file is sent in fixed
|
||||||
|
length blocks of 512 bytes. Each data packet contains one block of
|
||||||
|
data, and must be acknowledged by an acknowledgment packet before the
|
||||||
|
next packet can be sent. A data packet of less than 512 bytes
|
||||||
|
signals termination of a transfer. If a packet gets lost in the
|
||||||
|
network, the intended recipient will timeout and may retransmit his
|
||||||
|
last packet (which may be data or an acknowledgment), thus causing
|
||||||
|
the sender of the lost packet to retransmit that lost packet. The
|
||||||
|
sender has to keep just one packet on hand for retransmission, since
|
||||||
|
the lock step acknowledgment guarantees that all older packets have
|
||||||
|
been received. Notice that both machines involved in a transfer are
|
||||||
|
considered senders and receivers. One sends data and receives
|
||||||
|
acknowledgments, the other sends acknowledgments and receives data.
|
||||||
|
|
||||||
|
Most errors cause termination of the connection. An error is
|
||||||
|
signalled by sending an error packet. This packet is not
|
||||||
|
acknowledged, and not retransmitted (i.e., a TFTP server or user may
|
||||||
|
terminate after sending an error message), so the other end of the
|
||||||
|
connection may not get it. Therefore timeouts are used to detect
|
||||||
|
such a termination when the error packet has been lost. Errors are
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 2]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
caused by three types of events: not being able to satisfy the
|
||||||
|
request (e.g., file not found, access violation, or no such user),
|
||||||
|
receiving a packet which cannot be explained by a delay or
|
||||||
|
duplication in the network (e.g., an incorrectly formed packet), and
|
||||||
|
losing access to a necessary resource (e.g., disk full or access
|
||||||
|
denied during a transfer).
|
||||||
|
|
||||||
|
TFTP recognizes only one error condition that does not cause
|
||||||
|
termination, the source port of a received packet being incorrect.
|
||||||
|
In this case, an error packet is sent to the originating host.
|
||||||
|
|
||||||
|
This protocol is very restrictive, in order to simplify
|
||||||
|
implementation. For example, the fixed length blocks make allocation
|
||||||
|
straight forward, and the lock step acknowledgement provides flow
|
||||||
|
control and eliminates the need to reorder incoming data packets.
|
||||||
|
|
||||||
|
3. Relation to other Protocols
|
||||||
|
|
||||||
|
As mentioned TFTP is designed to be implemented on top of the
|
||||||
|
Datagram protocol (UDP). Since Datagram is implemented on the
|
||||||
|
Internet protocol, packets will have an Internet header, a Datagram
|
||||||
|
header, and a TFTP header. Additionally, the packets may have a
|
||||||
|
header (LNI, ARPA header, etc.) to allow them through the local
|
||||||
|
transport medium. As shown in Figure 3-1, the order of the contents
|
||||||
|
of a packet will be: local medium header, if used, Internet header,
|
||||||
|
Datagram header, TFTP header, followed by the remainder of the TFTP
|
||||||
|
packet. (This may or may not be data depending on the type of packet
|
||||||
|
as specified in the TFTP header.) TFTP does not specify any of the
|
||||||
|
values in the Internet header. On the other hand, the source and
|
||||||
|
destination port fields of the Datagram header (its format is given
|
||||||
|
in the appendix) are used by TFTP and the length field reflects the
|
||||||
|
size of the TFTP packet. The transfer identifiers (TID's) used by
|
||||||
|
TFTP are passed to the Datagram layer to be used as ports; therefore
|
||||||
|
they must be between 0 and 65,535. The initialization of TID's is
|
||||||
|
discussed in the section on initial connection protocol.
|
||||||
|
|
||||||
|
The TFTP header consists of a 2 byte opcode field which indicates
|
||||||
|
the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the
|
||||||
|
formats of the various types of packets are discussed further in the
|
||||||
|
section on TFTP packets.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 3]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
---------------------------------------------------
|
||||||
|
| Local Medium | Internet | Datagram | TFTP |
|
||||||
|
---------------------------------------------------
|
||||||
|
|
||||||
|
Figure 3-1: Order of Headers
|
||||||
|
|
||||||
|
|
||||||
|
4. Initial Connection Protocol
|
||||||
|
|
||||||
|
A transfer is established by sending a request (WRQ to write onto a
|
||||||
|
foreign file system, or RRQ to read from it), and receiving a
|
||||||
|
positive reply, an acknowledgment packet for write, or the first data
|
||||||
|
packet for read. In general an acknowledgment packet will contain
|
||||||
|
the block number of the data packet being acknowledged. Each data
|
||||||
|
packet has associated with it a block number; block numbers are
|
||||||
|
consecutive and begin with one. Since the positive response to a
|
||||||
|
write request is an acknowledgment packet, in this special case the
|
||||||
|
block number will be zero. (Normally, since an acknowledgment packet
|
||||||
|
is acknowledging a data packet, the acknowledgment packet will
|
||||||
|
contain the block number of the data packet being acknowledged.) If
|
||||||
|
the reply is an error packet, then the request has been denied.
|
||||||
|
|
||||||
|
In order to create a connection, each end of the connection chooses a
|
||||||
|
TID for itself, to be used for the duration of that connection. The
|
||||||
|
TID's chosen for a connection should be randomly chosen, so that the
|
||||||
|
probability that the same number is chosen twice in immediate
|
||||||
|
succession is very low. Every packet has associated with it the two
|
||||||
|
TID's of the ends of the connection, the source TID and the
|
||||||
|
destination TID. These TID's are handed to the supporting UDP (or
|
||||||
|
other datagram protocol) as the source and destination ports. A
|
||||||
|
requesting host chooses its source TID as described above, and sends
|
||||||
|
its initial request to the known TID 69 decimal (105 octal) on the
|
||||||
|
serving host. The response to the request, under normal operation,
|
||||||
|
uses a TID chosen by the server as its source TID and the TID chosen
|
||||||
|
for the previous message by the requestor as its destination TID.
|
||||||
|
The two chosen TID's are then used for the remainder of the transfer.
|
||||||
|
|
||||||
|
As an example, the following shows the steps used to establish a
|
||||||
|
connection to write a file. Note that WRQ, ACK, and DATA are the
|
||||||
|
names of the write request, acknowledgment, and data types of packets
|
||||||
|
respectively. The appendix contains a similar example for reading a
|
||||||
|
file.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 4]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
1. Host A sends a "WRQ" to host B with source= A's TID,
|
||||||
|
destination= 69.
|
||||||
|
|
||||||
|
2. Host B sends a "ACK" (with block number= 0) to host A with
|
||||||
|
source= B's TID, destination= A's TID.
|
||||||
|
|
||||||
|
At this point the connection has been established and the first data
|
||||||
|
packet can be sent by Host A with a sequence number of 1. In the
|
||||||
|
next step, and in all succeeding steps, the hosts should make sure
|
||||||
|
that the source TID matches the value that was agreed on in steps 1
|
||||||
|
and 2. If a source TID does not match, the packet should be
|
||||||
|
discarded as erroneously sent from somewhere else. An error packet
|
||||||
|
should be sent to the source of the incorrect packet, while not
|
||||||
|
disturbing the transfer. This can be done only if the TFTP in fact
|
||||||
|
receives a packet with an incorrect TID. If the supporting protocols
|
||||||
|
do not allow it, this particular error condition will not arise.
|
||||||
|
|
||||||
|
The following example demonstrates a correct operation of the
|
||||||
|
protocol in which the above situation can occur. Host A sends a
|
||||||
|
request to host B. Somewhere in the network, the request packet is
|
||||||
|
duplicated, and as a result two acknowledgments are returned to host
|
||||||
|
A, with different TID's chosen on host B in response to the two
|
||||||
|
requests. When the first response arrives, host A continues the
|
||||||
|
connection. When the second response to the request arrives, it
|
||||||
|
should be rejected, but there is no reason to terminate the first
|
||||||
|
connection. Therefore, if different TID's are chosen for the two
|
||||||
|
connections on host B and host A checks the source TID's of the
|
||||||
|
messages it receives, the first connection can be maintained while
|
||||||
|
the second is rejected by returning an error packet.
|
||||||
|
|
||||||
|
5. TFTP Packets
|
||||||
|
|
||||||
|
TFTP supports five types of packets, all of which have been mentioned
|
||||||
|
above:
|
||||||
|
|
||||||
|
opcode operation
|
||||||
|
1 Read request (RRQ)
|
||||||
|
2 Write request (WRQ)
|
||||||
|
3 Data (DATA)
|
||||||
|
4 Acknowledgment (ACK)
|
||||||
|
5 Error (ERROR)
|
||||||
|
|
||||||
|
The TFTP header of a packet contains the opcode associated with
|
||||||
|
that packet.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 5]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
2 bytes string 1 byte string 1 byte
|
||||||
|
------------------------------------------------
|
||||||
|
| Opcode | Filename | 0 | Mode | 0 |
|
||||||
|
------------------------------------------------
|
||||||
|
|
||||||
|
Figure 5-1: RRQ/WRQ packet
|
||||||
|
|
||||||
|
|
||||||
|
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
|
||||||
|
shown in Figure 5-1. The file name is a sequence of bytes in
|
||||||
|
netascii terminated by a zero byte. The mode field contains the
|
||||||
|
string "netascii", "octet", or "mail" (or any combination of upper
|
||||||
|
and lower case, such as "NETASCII", NetAscii", etc.) in netascii
|
||||||
|
indicating the three modes defined in the protocol. A host which
|
||||||
|
receives netascii mode data must translate the data to its own
|
||||||
|
format. Octet mode is used to transfer a file that is in the 8-bit
|
||||||
|
format of the machine from which the file is being transferred. It
|
||||||
|
is assumed that each type of machine has a single 8-bit format that
|
||||||
|
is more common, and that that format is chosen. For example, on a
|
||||||
|
DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
|
||||||
|
four bits of breakage. If a host receives a octet file and then
|
||||||
|
returns it, the returned file must be identical to the original.
|
||||||
|
Mail mode uses the name of a mail recipient in place of a file and
|
||||||
|
must begin with a WRQ. Otherwise it is identical to netascii mode.
|
||||||
|
The mail recipient string should be of the form "username" or
|
||||||
|
"username@hostname". If the second form is used, it allows the
|
||||||
|
option of mail forwarding by a relay computer.
|
||||||
|
|
||||||
|
The discussion above assumes that both the sender and recipient are
|
||||||
|
operating in the same mode, but there is no reason that this has to
|
||||||
|
be the case. For example, one might build a storage server. There
|
||||||
|
is no reason that such a machine needs to translate netascii into its
|
||||||
|
own form of text. Rather, the sender might send files in netascii,
|
||||||
|
but the storage server might simply store them without translation in
|
||||||
|
8-bit format. Another such situation is a problem that currently
|
||||||
|
exists on DEC-20 systems. Neither netascii nor octet accesses all
|
||||||
|
the bits in a word. One might create a special mode for such a
|
||||||
|
machine which read all the bits in a word, but in which the receiver
|
||||||
|
stored the information in 8-bit format. When such a file is
|
||||||
|
retrieved from the storage site, it must be restored to its original
|
||||||
|
form to be useful, so the reverse mode must also be implemented. The
|
||||||
|
user site will have to remember some information to achieve this. In
|
||||||
|
both of these examples, the request packets would specify octet mode
|
||||||
|
to the foreign host, but the local host would be in some other mode.
|
||||||
|
No such machine or application specific modes have been specified in
|
||||||
|
TFTP, but one would be compatible with this specification.
|
||||||
|
|
||||||
|
It is also possible to define other modes for cooperating pairs of
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 6]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
hosts, although this must be done with care. There is no requirement
|
||||||
|
that any other hosts implement these. There is no central authority
|
||||||
|
that will define these modes or assign them names.
|
||||||
|
|
||||||
|
|
||||||
|
2 bytes 2 bytes n bytes
|
||||||
|
----------------------------------
|
||||||
|
| Opcode | Block # | Data |
|
||||||
|
----------------------------------
|
||||||
|
|
||||||
|
Figure 5-2: DATA packet
|
||||||
|
|
||||||
|
|
||||||
|
Data is actually transferred in DATA packets depicted in Figure 5-2.
|
||||||
|
DATA packets (opcode = 3) have a block number and data field. The
|
||||||
|
block numbers on data packets begin with one and increase by one for
|
||||||
|
each new block of data. This restriction allows the program to use a
|
||||||
|
single number to discriminate between new packets and duplicates.
|
||||||
|
The data field is from zero to 512 bytes long. If it is 512 bytes
|
||||||
|
long, the block is not the last block of data; if it is from zero to
|
||||||
|
511 bytes long, it signals the end of the transfer. (See the section
|
||||||
|
on Normal Termination for details.)
|
||||||
|
|
||||||
|
All packets other than duplicate ACK's and those used for
|
||||||
|
termination are acknowledged unless a timeout occurs [4]. Sending a
|
||||||
|
DATA packet is an acknowledgment for the first ACK packet of the
|
||||||
|
previous DATA packet. The WRQ and DATA packets are acknowledged by
|
||||||
|
ACK or ERROR packets, while RRQ
|
||||||
|
|
||||||
|
|
||||||
|
2 bytes 2 bytes
|
||||||
|
---------------------
|
||||||
|
| Opcode | Block # |
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Figure 5-3: ACK packet
|
||||||
|
|
||||||
|
|
||||||
|
and ACK packets are acknowledged by DATA or ERROR packets. Figure
|
||||||
|
5-3 depicts an ACK packet; the opcode is 4. The block number in
|
||||||
|
an ACK echoes the block number of the DATA packet being
|
||||||
|
acknowledged. A WRQ is acknowledged with an ACK packet having a
|
||||||
|
block number of zero.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 7]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
2 bytes 2 bytes string 1 byte
|
||||||
|
-----------------------------------------
|
||||||
|
| Opcode | ErrorCode | ErrMsg | 0 |
|
||||||
|
-----------------------------------------
|
||||||
|
|
||||||
|
Figure 5-4: ERROR packet
|
||||||
|
|
||||||
|
|
||||||
|
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
|
||||||
|
ERROR packet can be the acknowledgment of any other type of packet.
|
||||||
|
The error code is an integer indicating the nature of the error. A
|
||||||
|
table of values and meanings is given in the appendix. (Note that
|
||||||
|
several error codes have been added to this version of this
|
||||||
|
document.) The error message is intended for human consumption, and
|
||||||
|
should be in netascii. Like all other strings, it is terminated with
|
||||||
|
a zero byte.
|
||||||
|
|
||||||
|
6. Normal Termination
|
||||||
|
|
||||||
|
The end of a transfer is marked by a DATA packet that contains
|
||||||
|
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
|
||||||
|
packet is acknowledged by an ACK packet like all other DATA packets.
|
||||||
|
The host acknowledging the final DATA packet may terminate its side
|
||||||
|
of the connection on sending the final ACK. On the other hand,
|
||||||
|
dallying is encouraged. This means that the host sending the final
|
||||||
|
ACK will wait for a while before terminating in order to retransmit
|
||||||
|
the final ACK if it has been lost. The acknowledger will know that
|
||||||
|
the ACK has been lost if it receives the final DATA packet again.
|
||||||
|
The host sending the last DATA must retransmit it until the packet is
|
||||||
|
acknowledged or the sending host times out. If the response is an
|
||||||
|
ACK, the transmission was completed successfully. If the sender of
|
||||||
|
the data times out and is not prepared to retransmit any more, the
|
||||||
|
transfer may still have been completed successfully, after which the
|
||||||
|
acknowledger or network may have experienced a problem. It is also
|
||||||
|
possible in this case that the transfer was unsuccessful. In any
|
||||||
|
case, the connection has been closed.
|
||||||
|
|
||||||
|
7. Premature Termination
|
||||||
|
|
||||||
|
If a request can not be granted, or some error occurs during the
|
||||||
|
transfer, then an ERROR packet (opcode 5) is sent. This is only a
|
||||||
|
courtesy since it will not be retransmitted or acknowledged, so it
|
||||||
|
may never be received. Timeouts must also be used to detect errors.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 8]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
I. Appendix
|
||||||
|
|
||||||
|
Order of Headers
|
||||||
|
|
||||||
|
2 bytes
|
||||||
|
----------------------------------------------------------
|
||||||
|
| Local Medium | Internet | Datagram | TFTP Opcode |
|
||||||
|
----------------------------------------------------------
|
||||||
|
|
||||||
|
TFTP Formats
|
||||||
|
|
||||||
|
Type Op # Format without header
|
||||||
|
|
||||||
|
2 bytes string 1 byte string 1 byte
|
||||||
|
-----------------------------------------------
|
||||||
|
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
|
||||||
|
WRQ -----------------------------------------------
|
||||||
|
2 bytes 2 bytes n bytes
|
||||||
|
---------------------------------
|
||||||
|
DATA | 03 | Block # | Data |
|
||||||
|
---------------------------------
|
||||||
|
2 bytes 2 bytes
|
||||||
|
-------------------
|
||||||
|
ACK | 04 | Block # |
|
||||||
|
--------------------
|
||||||
|
2 bytes 2 bytes string 1 byte
|
||||||
|
----------------------------------------
|
||||||
|
ERROR | 05 | ErrorCode | ErrMsg | 0 |
|
||||||
|
----------------------------------------
|
||||||
|
|
||||||
|
Initial Connection Protocol for reading a file
|
||||||
|
|
||||||
|
1. Host A sends a "RRQ" to host B with source= A's TID,
|
||||||
|
destination= 69.
|
||||||
|
|
||||||
|
2. Host B sends a "DATA" (with block number= 1) to host A with
|
||||||
|
source= B's TID, destination= A's TID.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 9]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
Error Codes
|
||||||
|
|
||||||
|
Value Meaning
|
||||||
|
|
||||||
|
0 Not defined, see error message (if any).
|
||||||
|
1 File not found.
|
||||||
|
2 Access violation.
|
||||||
|
3 Disk full or allocation exceeded.
|
||||||
|
4 Illegal TFTP operation.
|
||||||
|
5 Unknown transfer ID.
|
||||||
|
6 File already exists.
|
||||||
|
7 No such user.
|
||||||
|
|
||||||
|
Internet User Datagram Header [2]
|
||||||
|
|
||||||
|
(This has been included only for convenience. TFTP need not be
|
||||||
|
implemented on top of the Internet User Datagram Protocol.)
|
||||||
|
|
||||||
|
Format
|
||||||
|
|
||||||
|
0 1 2 3
|
||||||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| Source Port | Destination Port |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| Length | Checksum |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
|
||||||
|
|
||||||
|
Values of Fields
|
||||||
|
|
||||||
|
|
||||||
|
Source Port Picked by originator of packet.
|
||||||
|
|
||||||
|
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
|
||||||
|
|
||||||
|
Length Number of bytes in UDP packet, including UDP header.
|
||||||
|
|
||||||
|
Checksum Reference 2 describes rules for computing checksum.
|
||||||
|
(The implementor of this should be sure that the
|
||||||
|
correct algorithm is used here.)
|
||||||
|
Field contains zero if unused.
|
||||||
|
|
||||||
|
Note: TFTP passes transfer identifiers (TID's) to the Internet User
|
||||||
|
Datagram protocol to be used as the source and destination ports.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 10]
|
||||||
|
|
||||||
|
RFC 1350 TFTP Revision 2 July 1992
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
|
||||||
|
[1] USA Standard Code for Information Interchange, USASI X3.4-1968.
|
||||||
|
|
||||||
|
[2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
|
||||||
|
Sciences Institute, 28 August 1980.
|
||||||
|
|
||||||
|
[3] Postel, J., "Telnet Protocol Specification," RFC 764,
|
||||||
|
USC/Information Sciences Institute, June, 1980.
|
||||||
|
|
||||||
|
[4] Braden, R., Editor, "Requirements for Internet Hosts --
|
||||||
|
Application and Support", RFC 1123, USC/Information Sciences
|
||||||
|
Institute, October 1989.
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
|
||||||
|
Since TFTP includes no login or access control mechanisms, care must
|
||||||
|
be taken in the rights granted to a TFTP server process so as not to
|
||||||
|
violate the security of the server hosts file system. TFTP is often
|
||||||
|
installed with controls such that only files that have public read
|
||||||
|
access are available via TFTP and writing files via TFTP is
|
||||||
|
disallowed.
|
||||||
|
|
||||||
|
Author's Address
|
||||||
|
|
||||||
|
Karen R. Sollins
|
||||||
|
Massachusetts Institute of Technology
|
||||||
|
Laboratory for Computer Science
|
||||||
|
545 Technology Square
|
||||||
|
Cambridge, MA 02139-1986
|
||||||
|
|
||||||
|
Phone: (617) 253-6006
|
||||||
|
|
||||||
|
EMail: SOLLINS@LCS.MIT.EDU
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sollins [Page 11]
|
||||||
|
|
||||||
339
sources/DSS/rfc/rfc2090.txt
Normal file
339
sources/DSS/rfc/rfc2090.txt
Normal file
@ -0,0 +1,339 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group A. Emberson
|
||||||
|
Request for Comments: 2090 Lanworks Technologies Inc.
|
||||||
|
Category: Experimental February 1997
|
||||||
|
|
||||||
|
|
||||||
|
TFTP Multicast Option
|
||||||
|
|
||||||
|
Status of this Memo
|
||||||
|
|
||||||
|
This memo defines an Experimental Protocol for the Internet
|
||||||
|
community. This memo does not specify an Internet standard of any
|
||||||
|
kind. Discussion and suggestions for improvement are requested.
|
||||||
|
Distribution of this memo is unlimited.
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
|
||||||
|
transfer protocol which allows a client to get or put a file onto a
|
||||||
|
remote host.
|
||||||
|
|
||||||
|
This document describes a new TFTP option. This new option will allow
|
||||||
|
the multiple clients to receive the same file concurrently through
|
||||||
|
the use of Multicast packets. The TFTP Option Extension mechanism is
|
||||||
|
described in [2].
|
||||||
|
|
||||||
|
Often when similar computers are booting remotely they will each
|
||||||
|
download the same image file. By adding multicast into the TFTP
|
||||||
|
option set, two or more computers can download a file
|
||||||
|
concurrently, thus increasing network efficiency.
|
||||||
|
|
||||||
|
This document assumes that the reader is familiar with the
|
||||||
|
terminology and notation of both [1] and [2].
|
||||||
|
|
||||||
|
Multicast Option Specification
|
||||||
|
|
||||||
|
The TFTP Read Request packet is modified to include the multicast
|
||||||
|
option as follows:
|
||||||
|
|
||||||
|
+--------+----~~----+---+--~~--+---+-----------+---+---+
|
||||||
|
| opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
|
||||||
|
+--------+----~~----+---+--~~--+---+-----------+---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains a 1, for Read Requests, as defined
|
||||||
|
in [1].
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 1]
|
||||||
|
|
||||||
|
RFC 2090 TFTP Multicast Option February 1997
|
||||||
|
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read, as defined in [1]. This is a
|
||||||
|
NULL-terminated field.
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or
|
||||||
|
"mail", as defined in [1]. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
multicast
|
||||||
|
Request for multicast transmission of the file option,
|
||||||
|
"multicast" (case insensitive). This is a NULL-terminated
|
||||||
|
field. The value for this option request is a string of zero
|
||||||
|
length.
|
||||||
|
|
||||||
|
If the server is willing to accept the multicast option, it
|
||||||
|
sends an Option Acknowledgment (OACK) to the client including
|
||||||
|
the multicast option, as defined in [2]. The OACK to the client
|
||||||
|
will specify the multicast address and flag to indicate whether
|
||||||
|
that client should send block acknowledgments (ACK).
|
||||||
|
|
||||||
|
+-------+-----------+---+-------~~-------+---+
|
||||||
|
| opc | multicast | 0 | addr, port, mc | 0 |
|
||||||
|
+-------+-----------+---+-------~~-------+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains the number 6, for Option
|
||||||
|
Acknowledgment, as defined in [2].
|
||||||
|
|
||||||
|
multicast
|
||||||
|
Acknowledges the multicast option. This is a NULL-terminated
|
||||||
|
field.
|
||||||
|
|
||||||
|
addr
|
||||||
|
The addr field contains the multicast IP address. This field
|
||||||
|
is terminated with a comma.
|
||||||
|
|
||||||
|
port
|
||||||
|
The port field contains the destination port of the multicast
|
||||||
|
packets. The use of Registered Port number 1758 (tftp-mcast)
|
||||||
|
is recommended. This field is terminated with a comma.
|
||||||
|
|
||||||
|
mc
|
||||||
|
This field will be either 0 or 1, to tell the client whether
|
||||||
|
it is the master client, that is, it is responsible for
|
||||||
|
sending ACKs to the server. This is NULL-terminated field.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 2]
|
||||||
|
|
||||||
|
RFC 2090 TFTP Multicast Option February 1997
|
||||||
|
|
||||||
|
|
||||||
|
Data Transfer
|
||||||
|
|
||||||
|
After the OACK is received by the client it will send an ACK for
|
||||||
|
packet zero, as in [2]. With the multicast option being accepted this
|
||||||
|
ACK will indicate to the server that the client wants the first
|
||||||
|
packet. In other words the ACKs may now be seen as a request for the
|
||||||
|
n+1th block of data. This enables each a client to request any block
|
||||||
|
within the file that it may be missing.
|
||||||
|
|
||||||
|
To manage the data transfer the server will maintain a list of
|
||||||
|
clients. Typically the oldest client on the list, from here on
|
||||||
|
referred to as the Master Client, will be responsible for sending
|
||||||
|
ACKs. When the master client is finished, the server will send
|
||||||
|
another OACK to the next oldest client, telling it to start sending
|
||||||
|
ACKs. Upon receipt of this OACK the new master client will send an
|
||||||
|
ACK for the block immediately before the first block required to
|
||||||
|
complete its download.
|
||||||
|
|
||||||
|
Any subsequent clients can start receiving blocks of a file during a
|
||||||
|
transfer and then request any missing blocks when that client becomes
|
||||||
|
the master client. When the current master client is finished, the
|
||||||
|
server will notify the next client with an OACK making it the new
|
||||||
|
master client. The new master client can start requesting missed
|
||||||
|
packets. Each client must terminate the transfer by sending an
|
||||||
|
acknowledgment of the last packet or by sending an error message to
|
||||||
|
server. This termination can occur even if the client is not the
|
||||||
|
master client.
|
||||||
|
|
||||||
|
Any subsequent OACKs to a client may have an empty multicast address
|
||||||
|
and port fields, since this information will already be held by that
|
||||||
|
client. In the event a client fails to respond in a timely manner to
|
||||||
|
a OACK enabling it as the master client, the server shall select the
|
||||||
|
next oldest client to be the master client. The server shall
|
||||||
|
reattempt to send a OACK to the non- responding client when the new
|
||||||
|
master client is finished. The server may cease communication with a
|
||||||
|
client after a reasonable number of attempts.
|
||||||
|
|
||||||
|
Each transfer will be given a multicast address for use to distribute
|
||||||
|
the data packets. Since there can be multiple servers on a given
|
||||||
|
network or a limited number of addresses available to a given server,
|
||||||
|
it is possible that their might be more than one transfer using a
|
||||||
|
multicast address. To ensure that a client only accepts the correct
|
||||||
|
packets, each transfer must use a unique port on the server. The
|
||||||
|
source IP address and port number will identify the data packets for
|
||||||
|
the transfer. Thus the server must send the unicast OACK packet to
|
||||||
|
the client using the same port as will be used for sending the
|
||||||
|
multicast data packets.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 3]
|
||||||
|
|
||||||
|
RFC 2090 TFTP Multicast Option February 1997
|
||||||
|
|
||||||
|
|
||||||
|
At any point if a client, other than the master client, sends a ACK
|
||||||
|
to the server, the server will respond with another OACK with the mc
|
||||||
|
field holding a value of zero. If this client persists in sending
|
||||||
|
erroneous ACKs, the server may send an error packet to the client,
|
||||||
|
discontinuing the file transfer for that client.
|
||||||
|
|
||||||
|
The server may also send unicast packets to a lone client to reduce
|
||||||
|
adverse effects on other machines. As it is possible that machines
|
||||||
|
may be forced to process many extraneous multicast packets when
|
||||||
|
attempting to receive a single multicast address.
|
||||||
|
|
||||||
|
Example
|
||||||
|
|
||||||
|
clients server message
|
||||||
|
------------------------------------------------------------
|
||||||
|
1 C1 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
||||||
|
2 C1 <- |6|multicast|224.100.100.100,1758,1| OACK
|
||||||
|
3 C1 |4|0| -> ACK
|
||||||
|
4 M <- |3|1|1| 512 octets of data| DATA
|
||||||
|
5 C1 |4|1| -> ACK
|
||||||
|
6 M <- |3|2|1| 512 octets of data| DATA
|
||||||
|
7 C2 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
||||||
|
8 C2 <- |6|multicast|224.100.100.100,1758,0| OACK
|
||||||
|
9 C2 |4|0| -> ACK
|
||||||
|
10 C1 |4|2| -> ACK
|
||||||
|
11 M <- |3|3|1| 512 octets of data| DATA
|
||||||
|
12 C3 |1|afile|0|octet|0|multicast|0|0| -> RRQ
|
||||||
|
13 C3 <- |6|multicast|224.100.100.100,1758,0| OACK
|
||||||
|
14 C1 |4|3| -> ACK
|
||||||
|
15 C2 |4|0| -> ACK
|
||||||
|
16 M (except C2) <- |3|4|1| 512 octets of data| DATA
|
||||||
|
17 C1 |4|4| -> ACK
|
||||||
|
18 M <- |3|5|1| 512 octets of data| DATA
|
||||||
|
19 C1 |4|5| -> ACK
|
||||||
|
20 M <- |3|6|1| 100 octets of data| DATA
|
||||||
|
21 C1 |4|6| -> ACK
|
||||||
|
22 C2 <- |6|multicast|,,1| OACK
|
||||||
|
23 C2 |4|0| -> ACK
|
||||||
|
24 M <- |3|1|1| 512 octets of data| DATA
|
||||||
|
25 C2 |4|1| -> ACK
|
||||||
|
26 M <- |3|2|1| 512 octets of data| DATA
|
||||||
|
27 C2 |4|3| -> ACK
|
||||||
|
28 M <- |3|4|1| 512 octets of data| DATA
|
||||||
|
29 C2 |4|6| -> ACK
|
||||||
|
30 C3 <- |6|multicast|,,1| OACK
|
||||||
|
31 C3 |4|2| -> ACK
|
||||||
|
32 M <- |3|3|1| 512 octets of data| DATA
|
||||||
|
33 C3 |4|6| -> ACK
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 4]
|
||||||
|
|
||||||
|
RFC 2090 TFTP Multicast Option February 1997
|
||||||
|
|
||||||
|
|
||||||
|
Comments:
|
||||||
|
1 request from client 1
|
||||||
|
2 option acknowledgment
|
||||||
|
3 acknowledgment for option acknowledgment,
|
||||||
|
or request for first block of data
|
||||||
|
4 first data packet sent to the multicast address
|
||||||
|
7 request from client 2
|
||||||
|
8 option acknowledgment to client 2,
|
||||||
|
send no acknowledgments
|
||||||
|
9 OACK acknowledgment from client 2
|
||||||
|
15 OACK acknowledgment from client 3
|
||||||
|
16 client 2 fails to receive a packet
|
||||||
|
21 client 1 acknowledges receipt of the last block,
|
||||||
|
telling the server it is done
|
||||||
|
23 option acknowledgment to client 2,
|
||||||
|
now the master client
|
||||||
|
25 client 2 acknowledging with request for first block
|
||||||
|
27 client 2 acknowledges with request for missed block
|
||||||
|
29 client 2 signals it is finished
|
||||||
|
31 client 3 is master client and asks for missing blocks
|
||||||
|
33 client 3 signals it is finished
|
||||||
|
|
||||||
|
Conclusion
|
||||||
|
|
||||||
|
With the use of the multicast and blocksize[3] options TFTP will be
|
||||||
|
capable of fast and efficient downloads of data. Using TFTP with the
|
||||||
|
multicast option will maintain backward compatibility for both
|
||||||
|
clients and servers.
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
|
||||||
|
Security issues are not discussed in this memo.
|
||||||
|
|
||||||
|
References
|
||||||
|
|
||||||
|
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
|
||||||
|
1350, MIT, July 1992.
|
||||||
|
|
||||||
|
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC
|
||||||
|
1782, Xylogics, Inc., Hewlett Packard Co., March 1995.
|
||||||
|
|
||||||
|
[3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC
|
||||||
|
1783, Xylogics, Inc., Hewlett Packard Co., March 1995.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 5]
|
||||||
|
|
||||||
|
RFC 2090 TFTP Multicast Option February 1997
|
||||||
|
|
||||||
|
|
||||||
|
Author's Address
|
||||||
|
|
||||||
|
A. Thomas Emberson
|
||||||
|
Lanworks Technologies, Inc.
|
||||||
|
2425 Skymark Avenue
|
||||||
|
Mississauga, Ontario
|
||||||
|
Canada L4W 4Y6
|
||||||
|
|
||||||
|
|
||||||
|
Phone: (905) 238-5528
|
||||||
|
EMail: tom@lanworks.com
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Emberson Experimental [Page 6]
|
||||||
|
|
||||||
395
sources/DSS/rfc/rfc2347.txt
Normal file
395
sources/DSS/rfc/rfc2347.txt
Normal file
@ -0,0 +1,395 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group G. Malkin
|
||||||
|
Request for Commments: 2347 Bay Networks
|
||||||
|
Updates: 1350 A. Harkin
|
||||||
|
Obsoletes: 1782 Hewlett Packard Co.
|
||||||
|
Category: Standards Track May 1998
|
||||||
|
|
||||||
|
|
||||||
|
TFTP Option Extension
|
||||||
|
|
||||||
|
Status of this Memo
|
||||||
|
|
||||||
|
This document specifies an Internet standards track protocol for the
|
||||||
|
Internet community, and requests discussion and suggestions for
|
||||||
|
improvements. Please refer to the current edition of the "Internet
|
||||||
|
Official Protocol Standards" (STD 1) for the standardization state
|
||||||
|
and status of this protocol. Distribution of this memo is unlimited.
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
|
||||||
|
transfer protocol which allows a client to get or put a file onto a
|
||||||
|
remote host. This document describes a simple extension to TFTP to
|
||||||
|
allow option negotiation prior to the file transfer.
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
|
||||||
|
The option negotiation mechanism proposed in this document is a
|
||||||
|
backward-compatible extension to the TFTP protocol. It allows file
|
||||||
|
transfer options to be negotiated prior to the transfer using a
|
||||||
|
mechanism which is consistent with TFTP's Request Packet format. The
|
||||||
|
mechanism is kept simple by enforcing a request-respond-acknowledge
|
||||||
|
sequence, similar to the lock-step approach taken by TFTP itself.
|
||||||
|
|
||||||
|
While the option negotiation mechanism is general purpose, in that
|
||||||
|
many types of options may be negotiated, it was created to support
|
||||||
|
the Blocksize option defined in [2]. Additional options are defined
|
||||||
|
in [3].
|
||||||
|
|
||||||
|
Packet Formats
|
||||||
|
|
||||||
|
TFTP options are appended to the Read Request and Write Request
|
||||||
|
packets. A new type of TFTP packet, the Option Acknowledgment
|
||||||
|
(OACK), is used to acknowledge a client's option negotiation request.
|
||||||
|
A new error code, 8, is hereby defined to indicate that a transfer
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 1]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
should be terminated due to option negotiation.
|
||||||
|
|
||||||
|
Options are appended to a TFTP Read Request or Write Request packet
|
||||||
|
as follows:
|
||||||
|
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
|
||||||
|
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
|
||||||
|
|
||||||
|
>-------+---+---~~---+---+
|
||||||
|
< optN | 0 | valueN | 0 |
|
||||||
|
>-------+---+---~~---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains either a 1, for Read Requests, or 2,
|
||||||
|
for Write Requests, as defined in [1].
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read or written, as defined in [1].
|
||||||
|
This is a NULL-terminated field.
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or "mail",
|
||||||
|
as defined in [1]. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
opt1
|
||||||
|
The first option, in case-insensitive ASCII (e.g., blksize).
|
||||||
|
This is a NULL-terminated field.
|
||||||
|
|
||||||
|
value1
|
||||||
|
The value associated with the first option, in case-
|
||||||
|
insensitive ASCII. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
optN, valueN
|
||||||
|
The final option/value pair. Each NULL-terminated field is
|
||||||
|
specified in case-insensitive ASCII.
|
||||||
|
|
||||||
|
The options and values are all NULL-terminated, in keeping with the
|
||||||
|
original request format. If multiple options are to be negotiated,
|
||||||
|
they are appended to each other. The order in which options are
|
||||||
|
specified is not significant. The maximum size of a request packet
|
||||||
|
is 512 octets.
|
||||||
|
|
||||||
|
The OACK packet has the following format:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 2]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
| opc | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 |
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains a 6, for Option Acknowledgment.
|
||||||
|
|
||||||
|
opt1
|
||||||
|
The first option acknowledgment, copied from the original
|
||||||
|
request.
|
||||||
|
|
||||||
|
value1
|
||||||
|
The acknowledged value associated with the first option. If
|
||||||
|
and how this value may differ from the original request is
|
||||||
|
detailed in the specification for the option.
|
||||||
|
|
||||||
|
optN, valueN
|
||||||
|
The final option/value acknowledgment pair.
|
||||||
|
|
||||||
|
Negotiation Protocol
|
||||||
|
|
||||||
|
The client appends options at the end of the Read Request or Write
|
||||||
|
request packet, as shown above. Any number of options may be
|
||||||
|
specified; however, an option may only be specified once. The order
|
||||||
|
of the options is not significant.
|
||||||
|
|
||||||
|
If the server supports option negotiation, and it recognizes one or
|
||||||
|
more of the options specified in the request packet, the server may
|
||||||
|
respond with an Options Acknowledgment (OACK). Each option the
|
||||||
|
server recognizes, and accepts the value for, is included in the
|
||||||
|
OACK. Some options may allow alternate values to be proposed, but
|
||||||
|
this is an option specific feature. The server must not include in
|
||||||
|
the OACK any option which had not been specifically requested by the
|
||||||
|
client; that is, only the client may initiate option negotiation.
|
||||||
|
Options which the server does not support should be omitted from the
|
||||||
|
OACK; they should not cause an ERROR packet to be generated. If the
|
||||||
|
value of a supported option is invalid, the specification for that
|
||||||
|
option will indicate whether the server should simply omit the option
|
||||||
|
from the OACK, respond with an alternate value, or send an ERROR
|
||||||
|
packet, with error code 8, to terminate the transfer.
|
||||||
|
|
||||||
|
An option not acknowledged by the server must be ignored by the
|
||||||
|
client and server as if it were never requested. If multiple options
|
||||||
|
were requested, the client must use those options which were
|
||||||
|
acknowledged by the server and must not use those options which were
|
||||||
|
not acknowledged by the server.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 3]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
When the client appends options to the end of a Read Request packet,
|
||||||
|
three possible responses may be returned by the server:
|
||||||
|
|
||||||
|
OACK - acknowledge of Read Request and the options;
|
||||||
|
|
||||||
|
DATA - acknowledge of Read Request, but not the options;
|
||||||
|
|
||||||
|
ERROR - the request has been denied.
|
||||||
|
|
||||||
|
When the client appends options to the end of a Write Request packet,
|
||||||
|
three possible responses may be returned by the server:
|
||||||
|
|
||||||
|
OACK - acknowledge of Write Request and the options;
|
||||||
|
|
||||||
|
ACK - acknowledge of Write Request, but not the options;
|
||||||
|
|
||||||
|
ERROR - the request has been denied.
|
||||||
|
|
||||||
|
If a server implementation does not support option negotiation, it
|
||||||
|
will likely ignore any options appended to the client's request. In
|
||||||
|
this case, the server will return a DATA packet for a Read Request
|
||||||
|
and an ACK packet for a Write Request establishing normal TFTP data
|
||||||
|
transfer. In the event that a server returns an error for a request
|
||||||
|
which carries an option, the client may attempt to repeat the request
|
||||||
|
without appending any options. This implementation option would
|
||||||
|
handle servers which consider extraneous data in the request packet
|
||||||
|
to be erroneous.
|
||||||
|
|
||||||
|
Depending on the original transfer request there are two ways for a
|
||||||
|
client to confirm acceptance of a server's OACK. If the transfer was
|
||||||
|
initiated with a Read Request, then an ACK (with the data block
|
||||||
|
number set to 0) is sent by the client to confirm the values in the
|
||||||
|
server's OACK packet. If the transfer was initiated with a Write
|
||||||
|
Request, then the client begins the transfer with the first DATA
|
||||||
|
packet, using the negotiated values. If the client rejects the OACK,
|
||||||
|
then it sends an ERROR packet, with error code 8, to the server and
|
||||||
|
the transfer is terminated.
|
||||||
|
|
||||||
|
Once a client acknowledges an OACK, with an appropriate non-error
|
||||||
|
response, that client has agreed to use only the options and values
|
||||||
|
returned by the server. Remember that the server cannot request an
|
||||||
|
option; it can only respond to them. If the client receives an OACK
|
||||||
|
containing an unrequested option, it should respond with an ERROR
|
||||||
|
packet, with error code 8, and terminate the transfer.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 4]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Examples
|
||||||
|
|
||||||
|
Read Request
|
||||||
|
|
||||||
|
client server
|
||||||
|
-------------------------------------------------------
|
||||||
|
|1|foofile|0|octet|0|blksize|0|1432|0| --> RRQ
|
||||||
|
<-- |6|blksize|0|1432|0| OACK
|
||||||
|
|4|0| --> ACK
|
||||||
|
<-- |3|1| 1432 octets of data | DATA
|
||||||
|
|4|1| --> ACK
|
||||||
|
<-- |3|2| 1432 octets of data | DATA
|
||||||
|
|4|2| --> ACK
|
||||||
|
<-- |3|3|<1432 octets of data | DATA
|
||||||
|
|4|3| --> ACK
|
||||||
|
|
||||||
|
Write Request
|
||||||
|
|
||||||
|
client server
|
||||||
|
-------------------------------------------------------
|
||||||
|
|2|barfile|0|octet|0|blksize|0|2048|0| --> RRQ
|
||||||
|
<-- |6|blksize|0|2048|0| OACK
|
||||||
|
|3|1| 2048 octets of data | --> DATA
|
||||||
|
<-- |4|1| ACK
|
||||||
|
|3|2| 2048 octets of data | --> DATA
|
||||||
|
<-- |4|2| ACK
|
||||||
|
|3|3|<2048 octets of data | --> DATA
|
||||||
|
<-- |4|3| ACK
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
|
||||||
|
The basic TFTP protocol has no security mechanism. This is why it
|
||||||
|
has no rename, delete, or file overwrite capabilities. This document
|
||||||
|
does not add any security to TFTP; however, the specified extensions
|
||||||
|
do not add any additional security risks.
|
||||||
|
|
||||||
|
References
|
||||||
|
|
||||||
|
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
|
||||||
|
October 1992.
|
||||||
|
|
||||||
|
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
|
||||||
|
May 1998.
|
||||||
|
|
||||||
|
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
|
||||||
|
Size Options", RFC 2349, May 1998.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 5]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Authors' Addresses
|
||||||
|
|
||||||
|
Gary Scott Malkin
|
||||||
|
Bay Networks
|
||||||
|
8 Federal Street
|
||||||
|
Billerica, MA 01821
|
||||||
|
|
||||||
|
Phone: (978) 916-4237
|
||||||
|
EMail: gmalkin@baynetworks.com
|
||||||
|
|
||||||
|
|
||||||
|
Art Harkin
|
||||||
|
Internet Services Project
|
||||||
|
Information Networks Division
|
||||||
|
19420 Homestead Road MS 43LN
|
||||||
|
Cupertino, CA 95014
|
||||||
|
|
||||||
|
Phone: (408) 447-3755
|
||||||
|
EMail: ash@cup.hp.com
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 6]
|
||||||
|
|
||||||
|
RFC 2347 TFTP Option Extension May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Full Copyright Statement
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
This document and translations of it may be copied and furnished to
|
||||||
|
others, and derivative works that comment on or otherwise explain it
|
||||||
|
or assist in its implementation may be prepared, copied, published
|
||||||
|
and distributed, in whole or in part, without restriction of any
|
||||||
|
kind, provided that the above copyright notice and this paragraph are
|
||||||
|
included on all such copies and derivative works. However, this
|
||||||
|
document itself may not be modified in any way, such as by removing
|
||||||
|
the copyright notice or references to the Internet Society or other
|
||||||
|
Internet organizations, except as needed for the purpose of
|
||||||
|
developing Internet standards in which case the procedures for
|
||||||
|
copyrights defined in the Internet Standards process must be
|
||||||
|
followed, or as required to translate it into languages other than
|
||||||
|
English.
|
||||||
|
|
||||||
|
The limited permissions granted above are perpetual and will not be
|
||||||
|
revoked by the Internet Society or its successors or assigns.
|
||||||
|
|
||||||
|
This document and the information contained herein is provided on an
|
||||||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 7]
|
||||||
|
|
||||||
283
sources/DSS/rfc/rfc2348.txt
Normal file
283
sources/DSS/rfc/rfc2348.txt
Normal file
@ -0,0 +1,283 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group G. Malkin
|
||||||
|
Request for Commments: 2348 Bay Networks
|
||||||
|
Updates: 1350 A. Harkin
|
||||||
|
Obsoletes: 1783 Hewlett Packard Co.
|
||||||
|
Category: Standards Track May 1998
|
||||||
|
|
||||||
|
|
||||||
|
TFTP Blocksize Option
|
||||||
|
|
||||||
|
Status of this Memo
|
||||||
|
|
||||||
|
This document specifies an Internet standards track protocol for the
|
||||||
|
Internet community, and requests discussion and suggestions for
|
||||||
|
improvements. Please refer to the current edition of the "Internet
|
||||||
|
Official Protocol Standards" (STD 1) for the standardization state
|
||||||
|
and status of this protocol. Distribution of this memo is unlimited.
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
|
||||||
|
transfer protocol which allows a client to get or put a file onto a
|
||||||
|
remote host. One of its primary uses is the booting of diskless
|
||||||
|
nodes on a Local Area Network. TFTP is used because it is very
|
||||||
|
simple to implement in a small node's limited ROM space. However,
|
||||||
|
the choice of a 512-octet blocksize is not the most efficient for use
|
||||||
|
on a LAN whose MTU may 1500 octets or greater.
|
||||||
|
|
||||||
|
This document describes a TFTP option which allows the client and
|
||||||
|
server to negotiate a blocksize more applicable to the network
|
||||||
|
medium. The TFTP Option Extension mechanism is described in [2].
|
||||||
|
|
||||||
|
Blocksize Option Specification
|
||||||
|
|
||||||
|
The TFTP Read Request or Write Request packet is modified to include
|
||||||
|
the blocksize option as follows. Note that all fields except "opc"
|
||||||
|
are NULL-terminated.
|
||||||
|
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
| opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 |
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains either a 1, for Read Requests, or 2,
|
||||||
|
for Write Requests, as defined in [1].
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 1]
|
||||||
|
|
||||||
|
RFC 2348 TFTP Blocksize Option May 1998
|
||||||
|
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read or written, as defined in [1].
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or "mail",
|
||||||
|
as defined in [1].
|
||||||
|
|
||||||
|
blksize
|
||||||
|
The Blocksize option, "blksize" (case in-sensitive).
|
||||||
|
|
||||||
|
#octets
|
||||||
|
The number of octets in a block, specified in ASCII. Valid
|
||||||
|
values range between "8" and "65464" octets, inclusive. The
|
||||||
|
blocksize refers to the number of data octets; it does not
|
||||||
|
include the four octets of TFTP header.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
+-------+--------+---+--------+---+--------+---+--------+---+
|
||||||
|
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
|
||||||
|
+-------+--------+---+--------+---+--------+---+--------+---+
|
||||||
|
|
||||||
|
is a Read Request, for the file named "foobar", in octet (binary)
|
||||||
|
transfer mode, with a block size of 1428 octets (Ethernet MTU, less
|
||||||
|
the TFTP, UDP and IP header lengths).
|
||||||
|
|
||||||
|
If the server is willing to accept the blocksize option, it sends an
|
||||||
|
Option Acknowledgment (OACK) to the client. The specified value must
|
||||||
|
be less than or equal to the value specified by the client. The
|
||||||
|
client must then either use the size specified in the OACK, or send
|
||||||
|
an ERROR packet, with error code 8, to terminate the transfer.
|
||||||
|
|
||||||
|
The rules for determining the final packet are unchanged from [1].
|
||||||
|
The reception of a data packet with a data length less than the
|
||||||
|
negotiated blocksize is the final packet. If the blocksize is
|
||||||
|
greater than the amount of data to be transfered, the first packet is
|
||||||
|
the final packet. If the amount of data to be transfered is an
|
||||||
|
integral multiple of the blocksize, an extra data packet containing
|
||||||
|
no data is sent to end the transfer.
|
||||||
|
|
||||||
|
Proof of Concept
|
||||||
|
|
||||||
|
Performance tests were run on the prototype implementation using a
|
||||||
|
variety of block sizes. The tests were run on a lightly loaded
|
||||||
|
Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files.
|
||||||
|
The average (5x) transfer times for paths with (g-time) and without
|
||||||
|
(n-time) a intermediate gateway are graphed as follows:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 2]
|
||||||
|
|
||||||
|
RFC 2348 TFTP Blocksize Option May 1998
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
37 + g
|
||||||
|
|
|
||||||
|
35 +
|
||||||
|
|
|
||||||
|
33 +
|
||||||
|
|
|
||||||
|
31 +
|
||||||
|
|
|
||||||
|
29 +
|
||||||
|
|
|
||||||
|
27 +
|
||||||
|
| g blocksize n-time g-time
|
||||||
|
25 + --------- ------ ------
|
||||||
|
s | n 512 23.85 37.05
|
||||||
|
e 23 + g 1024 16.15 25.65
|
||||||
|
c | 1428 13.70 23.10
|
||||||
|
o 21 + 2048 10.90 16.90
|
||||||
|
n | 4096 6.85 9.65
|
||||||
|
d 19 + 8192 4.90 6.15
|
||||||
|
s |
|
||||||
|
17 + g
|
||||||
|
| n
|
||||||
|
15 +
|
||||||
|
| n
|
||||||
|
13 +
|
||||||
|
|
|
||||||
|
11 + n
|
||||||
|
| g
|
||||||
|
9 +
|
||||||
|
|
|
||||||
|
7 + n
|
||||||
|
| g
|
||||||
|
5 + n
|
||||||
|
"
|
||||||
|
0 +------+------+--+---+------+------+---
|
||||||
|
512 1K | 2K 4K 8K
|
||||||
|
1428
|
||||||
|
blocksize (octets)
|
||||||
|
|
||||||
|
The comparisons between transfer times (without a gateway) between
|
||||||
|
the standard 512-octet blocksize and the negotiated blocksizes are:
|
||||||
|
|
||||||
|
1024 2x -32%
|
||||||
|
1428 2.8x -42%
|
||||||
|
2048 4x -54%
|
||||||
|
4096 8x -71%
|
||||||
|
8192 16x -80%
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 3]
|
||||||
|
|
||||||
|
RFC 2348 TFTP Blocksize Option May 1998
|
||||||
|
|
||||||
|
|
||||||
|
As was anticipated, the transfer time decreases with an increase in
|
||||||
|
blocksize. The reason for the reduction in time is the reduction in
|
||||||
|
the number of packets sent. For example, by increasing the blocksize
|
||||||
|
from 512 octets to 1024 octets, not only are the number of data
|
||||||
|
packets halved, but the number of acknowledgement packets is also
|
||||||
|
halved (along with the number of times the data transmitter must wait
|
||||||
|
for an ACK). A secondary effect is the efficiency gained by reducing
|
||||||
|
the per-packet framing and processing overhead.
|
||||||
|
|
||||||
|
Of course, if the blocksize exceeds the path MTU, IP fragmentation
|
||||||
|
and reassembly will begin to add more overhead. This will be more
|
||||||
|
noticable the greater the number of gateways in the path.
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
|
||||||
|
The basic TFTP protocol has no security mechanism. This is why it
|
||||||
|
has no rename, delete, or file overwrite capabilities. This document
|
||||||
|
does not add any security to TFTP; however, the specified extensions
|
||||||
|
do not add any additional security risks.
|
||||||
|
|
||||||
|
References
|
||||||
|
|
||||||
|
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
|
||||||
|
October 1992.
|
||||||
|
|
||||||
|
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
|
||||||
|
May 1998.
|
||||||
|
|
||||||
|
Authors' Addresses
|
||||||
|
|
||||||
|
Gary Scott Malkin
|
||||||
|
Bay Networks
|
||||||
|
8 Federal Street
|
||||||
|
Billerica, MA 10821
|
||||||
|
|
||||||
|
Phone: (978) 916-4237
|
||||||
|
EMail: gmalkin@baynetworks.com
|
||||||
|
|
||||||
|
|
||||||
|
Art Harkin
|
||||||
|
Networked Computing Division
|
||||||
|
Hewlett-Packard Company
|
||||||
|
19420 Homestead Road MS 43LN
|
||||||
|
Cupertino, CA 95014
|
||||||
|
|
||||||
|
Phone: (408) 447-3755
|
||||||
|
EMail: ash@cup.hp.com
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 4]
|
||||||
|
|
||||||
|
RFC 2348 TFTP Blocksize Option May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Full Copyright Statement
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
This document and translations of it may be copied and furnished to
|
||||||
|
others, and derivative works that comment on or otherwise explain it
|
||||||
|
or assist in its implementation may be prepared, copied, published
|
||||||
|
and distributed, in whole or in part, without restriction of any
|
||||||
|
kind, provided that the above copyright notice and this paragraph are
|
||||||
|
included on all such copies and derivative works. However, this
|
||||||
|
document itself may not be modified in any way, such as by removing
|
||||||
|
the copyright notice or references to the Internet Society or other
|
||||||
|
Internet organizations, except as needed for the purpose of
|
||||||
|
developing Internet standards in which case the procedures for
|
||||||
|
copyrights defined in the Internet Standards process must be
|
||||||
|
followed, or as required to translate it into languages other than
|
||||||
|
English.
|
||||||
|
|
||||||
|
The limited permissions granted above are perpetual and will not be
|
||||||
|
revoked by the Internet Society or its successors or assigns.
|
||||||
|
|
||||||
|
This document and the information contained herein is provided on an
|
||||||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 5]
|
||||||
|
|
||||||
283
sources/DSS/rfc/rfc2349.txt
Normal file
283
sources/DSS/rfc/rfc2349.txt
Normal file
@ -0,0 +1,283 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group G. Malkin
|
||||||
|
Request for Commments: 2349 Bay Networks
|
||||||
|
Updates: 1350 A. Harkin
|
||||||
|
Obsoletes: 1784 Hewlett Packard Co.
|
||||||
|
Category: Standards Track May 1998
|
||||||
|
|
||||||
|
|
||||||
|
TFTP Timeout Interval and Transfer Size Options
|
||||||
|
|
||||||
|
Status of this Memo
|
||||||
|
|
||||||
|
This document specifies an Internet standards track protocol for the
|
||||||
|
Internet community, and requests discussion and suggestions for
|
||||||
|
improvements. Please refer to the current edition of the "Internet
|
||||||
|
Official Protocol Standards" (STD 1) for the standardization state
|
||||||
|
and status of this protocol. Distribution of this memo is unlimited.
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
|
||||||
|
transfer protocol which allows a client to get or put a file onto a
|
||||||
|
remote host.
|
||||||
|
|
||||||
|
This document describes two TFTP options. The first allows the client
|
||||||
|
and server to negotiate the Timeout Interval. The second allows the
|
||||||
|
side receiving the file to determine the ultimate size of the
|
||||||
|
transfer before it begins. The TFTP Option Extension mechanism is
|
||||||
|
described in [2].
|
||||||
|
|
||||||
|
Timeout Interval Option Specification
|
||||||
|
|
||||||
|
The TFTP Read Request or Write Request packet is modified to include
|
||||||
|
the timeout option as follows:
|
||||||
|
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
| opc |filename| 0 | mode | 0 | timeout| 0 | #secs | 0 |
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains either a 1, for Read Requests, or 2,
|
||||||
|
for Write Requests, as defined in [1].
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 1]
|
||||||
|
|
||||||
|
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
|
||||||
|
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read or written, as defined in [1].
|
||||||
|
This is a NULL-terminated field.
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or "mail",
|
||||||
|
as defined in [1]. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
timeout
|
||||||
|
The Timeout Interval option, "timeout" (case in-sensitive).
|
||||||
|
This is a NULL-terminated field.
|
||||||
|
|
||||||
|
#secs
|
||||||
|
The number of seconds to wait before retransmitting, specified
|
||||||
|
in ASCII. Valid values range between "1" and "255" seconds,
|
||||||
|
inclusive. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
+-------+--------+---+--------+---+--------+---+-------+---+
|
||||||
|
| 1 | foobar | 0 | octet | 0 | timeout| 0 | 1 | 0 |
|
||||||
|
+-------+--------+---+--------+---+--------+---+-------+---+
|
||||||
|
|
||||||
|
is a Read Request, for the file named "foobar", in octet (binary)
|
||||||
|
transfer mode, with a timeout interval of 1 second.
|
||||||
|
|
||||||
|
If the server is willing to accept the timeout option, it sends an
|
||||||
|
Option Acknowledgment (OACK) to the client. The specified timeout
|
||||||
|
value must match the value specified by the client.
|
||||||
|
|
||||||
|
Transfer Size Option Specification
|
||||||
|
|
||||||
|
The TFTP Read Request or Write Request packet is modified to include
|
||||||
|
the tsize option as follows:
|
||||||
|
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
| opc |filename| 0 | mode | 0 | tsize | 0 | size | 0 |
|
||||||
|
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains either a 1, for Read Requests, or 2,
|
||||||
|
for Write Requests, as defined in [1].
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read or written, as defined in [1].
|
||||||
|
This is a NULL-terminated field.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 2]
|
||||||
|
|
||||||
|
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
|
||||||
|
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or "mail",
|
||||||
|
as defined in [1]. This is a NULL-terminated field.
|
||||||
|
|
||||||
|
tsize
|
||||||
|
The Transfer Size option, "tsize" (case in-sensitive). This is
|
||||||
|
a NULL-terminated field.
|
||||||
|
|
||||||
|
size
|
||||||
|
The size of the file to be transfered. This is a NULL-
|
||||||
|
terminated field.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
+-------+--------+---+--------+---+--------+---+--------+---+
|
||||||
|
| 2 | foobar | 0 | octet | 0 | tsize | 0 | 673312 | 0 |
|
||||||
|
+-------+--------+---+--------+---+--------+---+--------+---+
|
||||||
|
|
||||||
|
is a Write Request, with the 673312-octet file named "foobar", in
|
||||||
|
octet (binary) transfer mode.
|
||||||
|
|
||||||
|
In Read Request packets, a size of "0" is specified in the request
|
||||||
|
and the size of the file, in octets, is returned in the OACK. If the
|
||||||
|
file is too large for the client to handle, it may abort the transfer
|
||||||
|
with an Error packet (error code 3). In Write Request packets, the
|
||||||
|
size of the file, in octets, is specified in the request and echoed
|
||||||
|
back in the OACK. If the file is too large for the server to handle,
|
||||||
|
it may abort the transfer with an Error packet (error code 3).
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
|
||||||
|
The basic TFTP protocol has no security mechanism. This is why it
|
||||||
|
has no rename, delete, or file overwrite capabilities. This document
|
||||||
|
does not add any security to TFTP; however, the specified extensions
|
||||||
|
do not add any additional security risks.
|
||||||
|
|
||||||
|
References
|
||||||
|
|
||||||
|
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
|
||||||
|
October 92.
|
||||||
|
|
||||||
|
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
|
||||||
|
May 1998.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 3]
|
||||||
|
|
||||||
|
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Authors' Addresses
|
||||||
|
|
||||||
|
Gary Scott Malkin
|
||||||
|
Bay Networks
|
||||||
|
8 Federal Street
|
||||||
|
Billerica, MA 01821
|
||||||
|
|
||||||
|
Phone: (978) 916-4237
|
||||||
|
EMail: gmalkin@baynetworks.com
|
||||||
|
|
||||||
|
|
||||||
|
Art Harkin
|
||||||
|
Internet Services Project
|
||||||
|
Information Networks Division
|
||||||
|
19420 Homestead Road MS 43LN
|
||||||
|
Cupertino, CA 95014
|
||||||
|
|
||||||
|
Phone: (408) 447-3755
|
||||||
|
EMail: ash@cup.hp.com
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 4]
|
||||||
|
|
||||||
|
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
|
||||||
|
|
||||||
|
|
||||||
|
Full Copyright Statement
|
||||||
|
|
||||||
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||||
|
|
||||||
|
This document and translations of it may be copied and furnished to
|
||||||
|
others, and derivative works that comment on or otherwise explain it
|
||||||
|
or assist in its implementation may be prepared, copied, published
|
||||||
|
and distributed, in whole or in part, without restriction of any
|
||||||
|
kind, provided that the above copyright notice and this paragraph are
|
||||||
|
included on all such copies and derivative works. However, this
|
||||||
|
document itself may not be modified in any way, such as by removing
|
||||||
|
the copyright notice or references to the Internet Society or other
|
||||||
|
Internet organizations, except as needed for the purpose of
|
||||||
|
developing Internet standards in which case the procedures for
|
||||||
|
copyrights defined in the Internet Standards process must be
|
||||||
|
followed, or as required to translate it into languages other than
|
||||||
|
English.
|
||||||
|
|
||||||
|
The limited permissions granted above are perpetual and will not be
|
||||||
|
revoked by the Internet Society or its successors or assigns.
|
||||||
|
|
||||||
|
This document and the information contained herein is provided on an
|
||||||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Malkin & Harkin Standards Track [Page 5]
|
||||||
|
|
||||||
507
sources/DSS/rfc/rfc7440.txt
Normal file
507
sources/DSS/rfc/rfc7440.txt
Normal file
@ -0,0 +1,507 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Internet Engineering Task Force (IETF) P. Masotta
|
||||||
|
Request for Comments: 7440 Serva
|
||||||
|
Category: Standards Track January 2015
|
||||||
|
ISSN: 2070-1721
|
||||||
|
|
||||||
|
|
||||||
|
TFTP Windowsize Option
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
The "Trivial File Transfer Protocol" (RFC 1350) is a simple,
|
||||||
|
lockstep, file transfer protocol that allows a client to get or put a
|
||||||
|
file onto a remote host. One of its primary uses is in the early
|
||||||
|
stages of nodes booting from a Local Area Network (LAN). TFTP has
|
||||||
|
been used for this application because it is very simple to
|
||||||
|
implement. The employment of a lockstep scheme limits throughput
|
||||||
|
when used on a LAN.
|
||||||
|
|
||||||
|
This document describes a TFTP option that allows the client and
|
||||||
|
server to negotiate a window size of consecutive blocks to send as an
|
||||||
|
alternative for replacing the single-block lockstep schema. The TFTP
|
||||||
|
option mechanism employed is described in "TFTP Option Extension"
|
||||||
|
(RFC 2347).
|
||||||
|
|
||||||
|
Status of This Memo
|
||||||
|
|
||||||
|
This is an Internet Standards Track document.
|
||||||
|
|
||||||
|
This document is a product of the Internet Engineering Task Force
|
||||||
|
(IETF). It represents the consensus of the IETF community. It has
|
||||||
|
received public review and has been approved for publication by the
|
||||||
|
Internet Engineering Steering Group (IESG). Further information on
|
||||||
|
Internet Standards is available in Section 2 of RFC 5741.
|
||||||
|
|
||||||
|
Information about the current status of this document, any errata,
|
||||||
|
and how to provide feedback on it may be obtained at
|
||||||
|
http://www.rfc-editor.org/info/rfc7440.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 1]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (c) 2015 IETF Trust and the persons identified as the
|
||||||
|
document authors. All rights reserved.
|
||||||
|
|
||||||
|
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||||
|
Provisions Relating to IETF Documents
|
||||||
|
(http://trustee.ietf.org/license-info) in effect on the date of
|
||||||
|
publication of this document. Please review these documents
|
||||||
|
carefully, as they describe your rights and restrictions with respect
|
||||||
|
to this document. Code Components extracted from this document must
|
||||||
|
include Simplified BSD License text as described in Section 4.e of
|
||||||
|
the Trust Legal Provisions and are provided without warranty as
|
||||||
|
described in the Simplified BSD License.
|
||||||
|
|
||||||
|
Table of Contents
|
||||||
|
|
||||||
|
1. Introduction ....................................................2
|
||||||
|
2. Conventions Used in This Document ...............................3
|
||||||
|
3. Windowsize Option Specification .................................3
|
||||||
|
4. Traffic Flow and Error Handling .................................4
|
||||||
|
5. Proof of Concept and Windowsize Evaluation ......................6
|
||||||
|
6. Congestion and Error Control ....................................7
|
||||||
|
7. Security Considerations .........................................8
|
||||||
|
8. References ......................................................9
|
||||||
|
8.1. Normative References .......................................9
|
||||||
|
Author's Address ...................................................9
|
||||||
|
|
||||||
|
1. Introduction
|
||||||
|
|
||||||
|
TFTP is virtually unused for Internet transfers today, TFTP is still
|
||||||
|
massively used in network boot/installation scenarios including EFI
|
||||||
|
(Extensible Firmware Interface). TFTP's inherently low transfer rate
|
||||||
|
has been, so far, partially mitigated by the use of the blocksize
|
||||||
|
negotiated extension [RFC2348]. Using this method, the original
|
||||||
|
limitation of 512-byte blocks are, in practice, replaced in Ethernet
|
||||||
|
environments by blocks no larger than 1468 Bytes to avoid IP block
|
||||||
|
fragmentation. This strategy produces insufficient results when
|
||||||
|
transferring big files, for example, the initial ramdisk of Linux
|
||||||
|
distributions or the PE images used in network installations by
|
||||||
|
Microsoft WDS/MDT/SCCM. Considering TFTP looks far from extinction
|
||||||
|
today, this document presents a negotiated extension, under the terms
|
||||||
|
of the "TFTP Option Extension" [RFC2347], that produces TFTP transfer
|
||||||
|
rates comparable to those achieved by modern file transfer protocols.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 2]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
2. Conventions Used in This Document
|
||||||
|
|
||||||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||||||
|
"OPTIONAL" in this document are to be interpreted as described in
|
||||||
|
[RFC2119].
|
||||||
|
|
||||||
|
In this document, these words will appear with that interpretation
|
||||||
|
only when in ALL CAPS. Lowercase uses of these words are not to be
|
||||||
|
interpreted as carrying the significance given in RFC 2119.
|
||||||
|
|
||||||
|
3. Windowsize Option Specification
|
||||||
|
|
||||||
|
The TFTP Read Request or Write Request packet is modified to include
|
||||||
|
the windowsize option as follows. Note that all fields except "opc"
|
||||||
|
MUST be ASCII strings followed by a single-byte NULL character.
|
||||||
|
|
||||||
|
2B string 1B string 1B string 1B string 1B
|
||||||
|
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
|
||||||
|
| opc |filename| 0 | mode | 0 | windowsize | 0 | #blocks| 0 |
|
||||||
|
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
|
||||||
|
|
||||||
|
opc
|
||||||
|
The opcode field contains either a 1 for Read Requests or a 2 for
|
||||||
|
Write Requests, as defined in [RFC1350].
|
||||||
|
|
||||||
|
filename
|
||||||
|
The name of the file to be read or written, as defined in
|
||||||
|
[RFC1350].
|
||||||
|
|
||||||
|
mode
|
||||||
|
The mode of the file transfer: "netascii", "octet", or "mail", as
|
||||||
|
defined in [RFC1350].
|
||||||
|
|
||||||
|
windowsize
|
||||||
|
The windowsize option, "windowsize" (case insensitive).
|
||||||
|
|
||||||
|
#blocks
|
||||||
|
The base-10 ASCII string representation of the number of blocks in
|
||||||
|
a window. The valid values range MUST be between 1 and 65535
|
||||||
|
blocks, inclusive. The windowsize refers to the number of
|
||||||
|
consecutive blocks transmitted before stopping and waiting for the
|
||||||
|
reception of the acknowledgment of the last block transmitted.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 3]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
+------+--------+----+-------+----+------------+----+----+----+
|
||||||
|
|0x0001| foobar |0x00| octet |0x00| windowsize |0x00| 16 |0x00|
|
||||||
|
+------+--------+----+-------+----+------------+----+----+----+
|
||||||
|
|
||||||
|
is a Read Request for the file named "foobar" in octet transfer mode
|
||||||
|
with a windowsize of 16 blocks (option blocksize is not negotiated in
|
||||||
|
this example, the default of 512 Bytes per block applies).
|
||||||
|
|
||||||
|
If the server is willing to accept the windowsize option, it sends an
|
||||||
|
Option Acknowledgment (OACK) to the client. The specified value MUST
|
||||||
|
be less than or equal to the value specified by the client. The
|
||||||
|
client MUST then either use the size specified in the OACK or send an
|
||||||
|
ERROR packet, with error code 8, to terminate the transfer.
|
||||||
|
|
||||||
|
The rules for determining the final packet are unchanged from
|
||||||
|
[RFC1350] and [RFC2348].
|
||||||
|
|
||||||
|
The reception of a data window with a number of blocks less than the
|
||||||
|
negotiated windowsize is the final window. If the windowsize is
|
||||||
|
greater than the amount of data to be transferred, the first window
|
||||||
|
is the final window.
|
||||||
|
|
||||||
|
4. Traffic Flow and Error Handling
|
||||||
|
|
||||||
|
The next diagram depicts a section of the traffic flow between the
|
||||||
|
Data Sender (DSND) and the Data Receiver (DRCV) parties on a generic
|
||||||
|
windowsize TFTP file transfer.
|
||||||
|
|
||||||
|
The DSND MUST cyclically send to the DRCV the agreed windowsize
|
||||||
|
consecutive data blocks before normally stopping and waiting for the
|
||||||
|
ACK of the transferred window. The DRCV MUST send to the DSND the
|
||||||
|
ACK of the last data block of the window in order to confirm a
|
||||||
|
successful data block window reception.
|
||||||
|
|
||||||
|
In the case of an expected ACK not timely reaching the DSND
|
||||||
|
(timeout), the last received ACK SHALL set the beginning of the next
|
||||||
|
windowsize data block window to be sent.
|
||||||
|
|
||||||
|
In the case of a data block sequence error, the DRCV SHOULD notify
|
||||||
|
the DSND by sending an ACK corresponding to the last data block
|
||||||
|
correctly received. The notified DSND SHOULD send a new data block
|
||||||
|
window whose beginning MUST be set based on the ACK received out of
|
||||||
|
sequence.
|
||||||
|
|
||||||
|
Traffic with windowsize = 1 MUST be equivalent to traffic specified
|
||||||
|
by [RFC1350].
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 4]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
For normative traffic not specifically addressed in this section,
|
||||||
|
please refer to [RFC1350] and its updates.
|
||||||
|
|
||||||
|
[ DRCV ] <---traffic---> [ DSND ]
|
||||||
|
ACK# -> <- Data Block# window block#
|
||||||
|
...
|
||||||
|
<- |DB n+01| 1
|
||||||
|
<- |DB n+02| 2
|
||||||
|
<- |DB n+03| 3
|
||||||
|
<- |DB n+04| 4
|
||||||
|
|ACK n+04| ->
|
||||||
|
<- |DB n+05| 1
|
||||||
|
Error |<- |DB n+06| 2
|
||||||
|
<- |DB n+07| 3
|
||||||
|
|ACK n+05| ->
|
||||||
|
<- |DB n+06| 1
|
||||||
|
<- |DB n+07| 2
|
||||||
|
<- |DB n+08| 3
|
||||||
|
<- |DB n+09| 4
|
||||||
|
|ACK n+09| ->
|
||||||
|
<- |DB n+10| 1
|
||||||
|
Error |<- |DB n+11| 2
|
||||||
|
<- |DB n+12| 3
|
||||||
|
|ACK n+10| ->| Error
|
||||||
|
<- |DB n+13| 4
|
||||||
|
- timeout -
|
||||||
|
<- |DB n+10| 1
|
||||||
|
<- |DB n+11| 2
|
||||||
|
<- |DB n+12| 3
|
||||||
|
<- |DB n+13| 4
|
||||||
|
|ACK n+13| ->
|
||||||
|
...
|
||||||
|
|
||||||
|
Section of a Windowsize = 4 TFTP Transfer
|
||||||
|
Including Errors and Error Recovery
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 5]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
5. Proof of Concept and Windowsize Evaluation
|
||||||
|
|
||||||
|
Performance tests were run on the prototype implementation using a
|
||||||
|
variety of windowsizes and a fixed blocksize of 1456 bytes. The
|
||||||
|
tests were run on a lightly loaded Gigabit Ethernet, between two
|
||||||
|
Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode,
|
||||||
|
transferring a 180 MByte file.
|
||||||
|
|
||||||
|
^
|
||||||
|
|
|
||||||
|
300 +
|
||||||
|
Seconds | windowsize | time (s)
|
||||||
|
| ---------- ------
|
||||||
|
| x 1 257
|
||||||
|
250 + 2 131
|
||||||
|
| 4 76
|
||||||
|
| 8 54
|
||||||
|
| 16 42
|
||||||
|
200 + 32 38
|
||||||
|
| 64 35
|
||||||
|
|
|
||||||
|
|
|
||||||
|
150 +
|
||||||
|
|
|
||||||
|
| x
|
||||||
|
|
|
||||||
|
100 +
|
||||||
|
|
|
||||||
|
| x
|
||||||
|
|
|
||||||
|
50 + x
|
||||||
|
| x
|
||||||
|
| x x
|
||||||
|
|
|
||||||
|
0 +-//--+-----+-----+-----+-----+-----+-----+-->
|
||||||
|
1 2 4 8 16 32 64
|
||||||
|
|
||||||
|
Windowsize (in Blocks of 1456 Bytes)
|
||||||
|
|
||||||
|
Comparatively, the same 180 MB transfer performed over a drive mapped
|
||||||
|
on Server Message Block (SMB) / Common Internet File System (CIFS) on
|
||||||
|
the same scenario took 23 seconds.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 6]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
The comparison of transfer times (without a gateway) between the
|
||||||
|
standard lockstep schema and the negotiated windowsizes are:
|
||||||
|
|
||||||
|
Windowsize | Time Reduction (%)
|
||||||
|
---------- -----------------
|
||||||
|
1 -0%
|
||||||
|
2 -49%
|
||||||
|
4 -70%
|
||||||
|
8 -79%
|
||||||
|
16 -84%
|
||||||
|
32 -85%
|
||||||
|
64 -86%
|
||||||
|
|
||||||
|
The transfer time decreases with the use of a windowed schema. The
|
||||||
|
reason for the reduction in time is the reduction in the number of
|
||||||
|
the required synchronous acknowledgements exchanged.
|
||||||
|
|
||||||
|
The choice of appropriate windowsize values on a particular scenario
|
||||||
|
depends on the underlying networking technology and topology, and
|
||||||
|
likely other factors as well. Operators SHOULD test various values
|
||||||
|
and SHOULD be conservative when selecting a windowsize value because
|
||||||
|
as the former table and chart shows, there is a point where the
|
||||||
|
benefit of continuing to increase the windowsize is subject to
|
||||||
|
diminishing returns.
|
||||||
|
|
||||||
|
6. Congestion and Error Control
|
||||||
|
|
||||||
|
From a congestion control (CC) standpoint, the number of blocks in a
|
||||||
|
window does not pose an intrinsic threat to the ability of
|
||||||
|
intermediate devices to signal congestion through drops. The rate at
|
||||||
|
which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in
|
||||||
|
Section 3.1 of [RFC5405].
|
||||||
|
|
||||||
|
From an error control standpoint, while [RFC1350] and subsequent
|
||||||
|
updates do not specify a circuit breaker (CB), existing
|
||||||
|
implementations have always chosen to fail under certain
|
||||||
|
circumstances. Implementations SHOULD always set a maximum number of
|
||||||
|
retries for datagram retransmissions, imposing an appropriate
|
||||||
|
threshold on error recovery attempts, after which a transfer SHOULD
|
||||||
|
always be aborted to prevent pathological retransmission conditions.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 7]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
An implementation example scaled for an Ethernet environment
|
||||||
|
(1 Gbit/s, MTU=1500) would be to set:
|
||||||
|
|
||||||
|
windowsize = 8
|
||||||
|
blksize = 1456
|
||||||
|
maximum retransmission attempts per block/window = 6
|
||||||
|
timeout between retransmissions = 1 S
|
||||||
|
minimum inter-packet delay = 80 uS
|
||||||
|
|
||||||
|
Implementations might well choose other values based on expected
|
||||||
|
and/or tested operating conditions.
|
||||||
|
|
||||||
|
7. Security Considerations
|
||||||
|
|
||||||
|
TFTP includes no login or access control mechanisms. Care must be
|
||||||
|
taken when using TFTP for file transfers where authentication, access
|
||||||
|
control, confidentiality, or integrity checking are needed. Note
|
||||||
|
that those security services could be supplied above or below the
|
||||||
|
layer at which TFTP runs. Care must also be taken in the rights
|
||||||
|
granted to a TFTP server process so as not to violate the security of
|
||||||
|
the server's file system. TFTP is often installed with controls such
|
||||||
|
that only files that have public read access are available via TFTP.
|
||||||
|
Also listing, deleting, renaming, and writing files via TFTP are
|
||||||
|
typically disallowed. TFTP file transfers are NOT RECOMMENDED where
|
||||||
|
the inherent protocol limitations could raise insurmountable
|
||||||
|
liability concerns.
|
||||||
|
|
||||||
|
TFTP includes no protection against an on-path attacker; care must be
|
||||||
|
taken in controlling windowsize values according to data sender, data
|
||||||
|
receiver, and network environment capabilities. TFTP service is
|
||||||
|
frequently associated with bootstrap and initial provisioning
|
||||||
|
activities; servers in such an environment are in a position to
|
||||||
|
impose device or network specific throughput limitations as
|
||||||
|
appropriate.
|
||||||
|
|
||||||
|
This document does not add any security controls to TFTP; however,
|
||||||
|
the specified extension does not pose additional security risks
|
||||||
|
either.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 8]
|
||||||
|
|
||||||
|
RFC 7440 TFTP Windowsize Option January 2015
|
||||||
|
|
||||||
|
|
||||||
|
8. References
|
||||||
|
|
||||||
|
8.1. Normative References
|
||||||
|
|
||||||
|
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
|
||||||
|
RFC 1350, July 1992,
|
||||||
|
<http://www.rfc-editor.org/info/rfc1350>.
|
||||||
|
|
||||||
|
[RFC2347] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC
|
||||||
|
2347, May 1998, <http://www.rfc-editor.org/info/rfc2347>.
|
||||||
|
|
||||||
|
[RFC2348] Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC
|
||||||
|
2348, May 1998, <http://www.rfc-editor.org/info/rfc2348>.
|
||||||
|
|
||||||
|
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
|
||||||
|
Guidelines for Application Designers", BCP 145, RFC 5405,
|
||||||
|
November 2008, <http://www.rfc-editor.org/info/rfc5405>.
|
||||||
|
|
||||||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||||
|
Requirement Levels", BCP 14, RFC 2119, March 1997,
|
||||||
|
<http://www.rfc-editor.org/info/rfc2119>.
|
||||||
|
|
||||||
|
Author's Address
|
||||||
|
|
||||||
|
Patrick Masotta
|
||||||
|
Serva
|
||||||
|
|
||||||
|
EMail: patrick.masotta.ietf@vercot.com
|
||||||
|
URI: http://www.vercot.com/~serva/
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Masotta Standards Track [Page 9]
|
||||||
|
|
||||||
@ -4,6 +4,9 @@
|
|||||||
; https://github.com/romychs
|
; https://github.com/romychs
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
IFNDEF _SPRINTER
|
||||||
|
DEFINE _SPRINTER
|
||||||
|
|
||||||
; Memory pages
|
; Memory pages
|
||||||
PAGE0_ADDR EQU 0x0000
|
PAGE0_ADDR EQU 0x0000
|
||||||
PAGE1_ADDR EQU 0x4000
|
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_PRE EQU 0x20 ; 1 - 256 Prescaler, 0 - 16
|
||||||
CTC_CT_CTR EQU 0x40 ; 0 - Timer, 1 - Counter
|
CTC_CT_CTR EQU 0x40 ; 0 - Timer, 1 - Counter
|
||||||
CTC_CT_EI EQU 0x80 ; Interrupt 1 - enable, 0 - disable
|
CTC_CT_EI EQU 0x80 ; Interrupt 1 - enable, 0 - disable
|
||||||
|
|
||||||
|
ENDIF
|
||||||
@ -5,6 +5,9 @@
|
|||||||
; License: BSD 3-Clause
|
; License: BSD 3-Clause
|
||||||
; ======================================================
|
; ======================================================
|
||||||
|
|
||||||
|
IFNDEF _UTIL_ASM
|
||||||
|
DEFINE _UTIL_ASM
|
||||||
|
|
||||||
MODULE UTIL
|
MODULE UTIL
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
@ -29,8 +32,6 @@ DELAY_NXT
|
|||||||
POP HL,BC,AF
|
POP HL,BC,AF
|
||||||
RET
|
RET
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
DELAY_1MS_INT
|
DELAY_1MS_INT
|
||||||
LD BC,400
|
LD BC,400
|
||||||
SBD_NXT
|
SBD_NXT
|
||||||
@ -40,15 +41,18 @@ SBD_NXT
|
|||||||
JR NZ, SBD_NXT
|
JR NZ, SBD_NXT
|
||||||
RET
|
RET
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Delay for about 1ms
|
||||||
|
; ------------------------------------------------------
|
||||||
DELAY_1MS
|
DELAY_1MS
|
||||||
PUSH BC
|
PUSH BC
|
||||||
CALL DELAY_1MS_INT
|
CALL DELAY_1MS_INT
|
||||||
POP BC
|
POP BC
|
||||||
RET
|
RET
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Delay for about 100us
|
||||||
|
; ------------------------------------------------------
|
||||||
DELAY_100uS
|
DELAY_100uS
|
||||||
PUSH BC
|
PUSH BC
|
||||||
LD BC,40
|
LD BC,40
|
||||||
@ -56,12 +60,12 @@ DELAY_100uS
|
|||||||
POP BC
|
POP BC
|
||||||
RET
|
RET
|
||||||
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Calc length of zero ended string
|
; Calc length of zero ended string
|
||||||
; Inp: HL - pointer to string
|
; Inp: HL - pointer to string
|
||||||
; Out: BC - length of string
|
; Out: BC - length of string
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED STRLEN
|
||||||
STRLEN
|
STRLEN
|
||||||
PUSH DE,HL,HL
|
PUSH DE,HL,HL
|
||||||
LD BC,MAX_BUFF_SIZE
|
LD BC,MAX_BUFF_SIZE
|
||||||
@ -77,12 +81,14 @@ STRLEN
|
|||||||
STRL_NCOR
|
STRL_NCOR
|
||||||
POP HL,DE
|
POP HL,DE
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Compare zero-ended strings
|
; 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
|
; Out: CF=0 - equal, CF=1 - not equal
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED STRCMP
|
||||||
STRCMP
|
STRCMP
|
||||||
PUSH DE,HL
|
PUSH DE,HL
|
||||||
STC_NEXT
|
STC_NEXT
|
||||||
@ -99,12 +105,69 @@ STC_NE
|
|||||||
STC_EQ
|
STC_EQ
|
||||||
POP HL,DE
|
POP HL,DE
|
||||||
RET
|
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
|
; Convert string to number
|
||||||
; Inp: DE - ptr to zero ended string
|
; Inp: DE - ptr to zero ended string
|
||||||
; Out: HL - Result
|
; Out: HL - Result
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED ATOU
|
||||||
ATOU
|
ATOU
|
||||||
PUSH BC
|
PUSH BC
|
||||||
LD HL,0x0000
|
LD HL,0x0000
|
||||||
@ -130,7 +193,7 @@ ATOU_L1
|
|||||||
ATOU_LE
|
ATOU_LE
|
||||||
POP BC
|
POP BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Find char in string
|
; Find char in string
|
||||||
@ -139,6 +202,7 @@ ATOU_LE
|
|||||||
; Outp: CF=0, HL points to char if found
|
; Outp: CF=0, HL points to char if found
|
||||||
; CF=1 - Not found
|
; CF=1 - Not found
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED STRCHR
|
||||||
STRCHR
|
STRCHR
|
||||||
PUSH BC
|
PUSH BC
|
||||||
STCH_NEXT
|
STCH_NEXT
|
||||||
@ -155,30 +219,33 @@ STCH_N_FOUND
|
|||||||
STCH_FOUND
|
STCH_FOUND
|
||||||
POP BC
|
POP BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Convert Byte to hex
|
; Convert Byte to hex
|
||||||
; Inp: C
|
; Inp: C
|
||||||
; Out: (DE)
|
; Out: (DE)
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED HEXB
|
||||||
HEXB
|
HEXB
|
||||||
LD A,C
|
LD A,C
|
||||||
RRA
|
RRA
|
||||||
RRA
|
RRA
|
||||||
RRA
|
RRA
|
||||||
RRA
|
RRA
|
||||||
CALL CONV_NIBLE
|
CALL CONV_NIBLE
|
||||||
LD A,C
|
LD A,C
|
||||||
CONV_NIBLE
|
CONV_NIBLE
|
||||||
AND 0x0f
|
AND 0x0f
|
||||||
ADD A,0x90
|
ADD A,0x90
|
||||||
DAA
|
DAA
|
||||||
ADC A,0x40
|
ADC A,0x40
|
||||||
DAA
|
DAA
|
||||||
LD (DE), A
|
LD (DE), A
|
||||||
INC DE
|
INC DE
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
|
|
||||||
ENDMODULE
|
ENDMODULE
|
||||||
|
|
||||||
|
ENDIF
|
||||||
@ -12,7 +12,7 @@ ENABLE_RTS_CTR EQU 1
|
|||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Ckeck for error (CF=1) print message and exit
|
; Ckeck for error (CF=1) print message and exit
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED CHECK_ERROR
|
||||||
CHECK_ERROR
|
CHECK_ERROR
|
||||||
RET NC
|
RET NC
|
||||||
ADD A,'0'
|
ADD A,'0'
|
||||||
@ -21,18 +21,23 @@ CHECK_ERROR
|
|||||||
CALL DUMP_UART_REGS
|
CALL DUMP_UART_REGS
|
||||||
LD B,3
|
LD B,3
|
||||||
POP HL ; ret addr reset
|
POP HL ; ret addr reset
|
||||||
|
ENDIF
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Program exit point
|
||||||
|
; ------------------------------------------------------
|
||||||
|
IFUSED EXIT
|
||||||
EXIT
|
EXIT
|
||||||
CALL REST_VMODE
|
CALL REST_VMODE
|
||||||
LD C,DSS_EXIT
|
LD C,DSS_EXIT
|
||||||
RST DSS
|
RST DSS
|
||||||
|
ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Search Sprinter WiFi card
|
; Search Sprinter WiFi card
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED FIND_SWF
|
||||||
FIND_SWF
|
FIND_SWF
|
||||||
; Find Sprinter-WiFi
|
; Find Sprinter-WiFi
|
||||||
CALL WIFI.UART_FIND
|
CALL @WIFI.UART_FIND
|
||||||
JP C, NO_TL_FOUND
|
JP C, NO_TL_FOUND
|
||||||
LD A,(ISA.ISA_SLOT)
|
LD A,(ISA.ISA_SLOT)
|
||||||
ADD A,'1'
|
ADD A,'1'
|
||||||
@ -45,57 +50,59 @@ NO_TL_FOUND
|
|||||||
PRINTLN MSG_SWF_NOF
|
PRINTLN MSG_SWF_NOF
|
||||||
LD B,2
|
LD B,2
|
||||||
JP EXIT
|
JP EXIT
|
||||||
|
ENDIF
|
||||||
|
|
||||||
|
|
||||||
IF TRACE
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Dump all UTL16C550 registers to screen for debug
|
; Dump all UTL16C550 registers to screen for debug
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED DUMP_UART_REGS
|
||||||
|
IF TRACE
|
||||||
DUMP_UART_REGS
|
DUMP_UART_REGS
|
||||||
; Dump, DLAB=0 registers
|
; Dump, DLAB=0 registers
|
||||||
LD BC, 0x0800
|
LD BC, 0x0800
|
||||||
CALL DUMP_REGS
|
CALL DUMP_REGS
|
||||||
|
|
||||||
; Dump, DLAB=1 registers
|
; Dump, DLAB=1 registers
|
||||||
LD HL, REG_LCR
|
LD HL, REG_LCR
|
||||||
LD E, LCR_DLAB | LCR_WL8
|
LD E, LCR_DLAB | LCR_WL8
|
||||||
CALL WIFI.UART_WRITE
|
CALL WIFI.UART_WRITE
|
||||||
|
|
||||||
LD BC, 0x0210
|
LD BC, 0x0210
|
||||||
CALL DUMP_REGS
|
CALL DUMP_REGS
|
||||||
|
|
||||||
LD HL, REG_LCR
|
LD HL, REG_LCR
|
||||||
LD E, LCR_WL8
|
LD E, LCR_WL8
|
||||||
CALL WIFI.UART_WRITE
|
CALL WIFI.UART_WRITE
|
||||||
RET
|
RET
|
||||||
|
|
||||||
DUMP_REGS
|
DUMP_REGS
|
||||||
LD HL, PORT_UART_A
|
LD HL, PORT_UART_A
|
||||||
|
|
||||||
DR_NEXT
|
DR_NEXT
|
||||||
LD DE,MSG_DR_RN
|
LD DE,MSG_DR_RN
|
||||||
CALL UTIL.HEXB
|
CALL @UTIL.HEXB
|
||||||
INC C
|
INC C
|
||||||
|
|
||||||
CALL WIFI.UART_READ
|
CALL WIFI.UART_READ
|
||||||
PUSH BC
|
PUSH BC
|
||||||
LD C,A
|
LD C,A
|
||||||
LD DE,MSG_DR_RV
|
LD DE,MSG_DR_RV
|
||||||
CALL UTIL.HEXB
|
CALL @UTIL.HEXB
|
||||||
PUSH HL
|
PUSH HL
|
||||||
|
|
||||||
PRINTLN MSG_DR
|
PRINTLN MSG_DR
|
||||||
|
|
||||||
POP HL,BC
|
POP HL,BC
|
||||||
INC HL
|
INC HL
|
||||||
DJNZ DR_NEXT
|
DJNZ DR_NEXT
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
ENDIF
|
ENDIF
|
||||||
|
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Store old video mode, set 80x32 and clear
|
; Store old video mode, set 80x32 and clear
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED INIT_VMODE
|
||||||
INIT_VMODE
|
INIT_VMODE
|
||||||
PUSH BC,DE,HL
|
PUSH BC,DE,HL
|
||||||
; Store previous vmode
|
; Store previous vmode
|
||||||
@ -119,10 +126,11 @@ IVM_ALRDY_80
|
|||||||
|
|
||||||
POP HL,DE,BC
|
POP HL,DE,BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Restore saved video mode
|
; Restore saved video mode
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED REST_VMODE
|
||||||
REST_VMODE
|
REST_VMODE
|
||||||
PUSH BC
|
PUSH BC
|
||||||
LD A,(SAVE_VMODE)
|
LD A,(SAVE_VMODE)
|
||||||
@ -139,13 +147,15 @@ REST_VMODE
|
|||||||
RVM_SAME
|
RVM_SAME
|
||||||
POP BC
|
POP BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Init basic parameters of ESP
|
; Init basic parameters of ESP
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED INIT_ESP
|
||||||
INIT_ESP
|
INIT_ESP
|
||||||
PUSH BC, DE
|
PUSH BC, DE
|
||||||
LD DE, WIFI.RS_BUFF
|
LD DE, @WIFI.RS_BUFF
|
||||||
LD BC, DEFAULT_TIMEOUT
|
LD BC, DEFAULT_TIMEOUT
|
||||||
|
|
||||||
TRACELN MSG_ECHO_OFF
|
TRACELN MSG_ECHO_OFF
|
||||||
@ -166,11 +176,12 @@ INIT_ESP
|
|||||||
SEND_CMD CMD_CWLAP_OPT
|
SEND_CMD CMD_CWLAP_OPT
|
||||||
POP DE,BC
|
POP DE,BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Set DHCP mode
|
; Set DHCP mode
|
||||||
; Out: CF=1 if error
|
; Out: CF=1 if error
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED SET_DHCP_MODE
|
||||||
SET_DHCP_MODE
|
SET_DHCP_MODE
|
||||||
PUSH BC,DE
|
PUSH BC,DE
|
||||||
LD DE, WIFI.RS_BUFF
|
LD DE, WIFI.RS_BUFF
|
||||||
@ -179,17 +190,19 @@ SET_DHCP_MODE
|
|||||||
SEND_CMD CMD_SET_DHCP
|
SEND_CMD CMD_SET_DHCP
|
||||||
POP DE,BC
|
POP DE,BC
|
||||||
RET
|
RET
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Messages
|
; Messages
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
|
IFUSED FIND_SWF
|
||||||
MSG_SWF_NOF
|
MSG_SWF_NOF
|
||||||
DB "Sprinter-WiFi not found!",0
|
DB "Sprinter-WiFi not found!",0
|
||||||
|
|
||||||
MSG_SWF_FOUND
|
MSG_SWF_FOUND
|
||||||
DB "Sprinter-WiFi found in ISA#"
|
DB "Sprinter-WiFi found in ISA#"
|
||||||
MSG_SLOT_NO
|
MSG_SLOT_NO
|
||||||
DB "n slot.",0
|
DB "n slot.",0
|
||||||
|
ENDIF
|
||||||
|
|
||||||
MSG_COMM_ERROR
|
MSG_COMM_ERROR
|
||||||
DB "Error communication with Sprinter-WiFi #"
|
DB "Error communication with Sprinter-WiFi #"
|
||||||
@ -209,14 +222,15 @@ MSG_UART_INIT
|
|||||||
LINE_END
|
LINE_END
|
||||||
DB "\r\n",0
|
DB "\r\n",0
|
||||||
|
|
||||||
|
IFUSED INIT_VMODE
|
||||||
SAVE_VMODE
|
SAVE_VMODE
|
||||||
DB 0
|
DB 0
|
||||||
|
ENDIF
|
||||||
|
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Debug messages
|
; Debug messages
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
IF TRACE
|
IF TRACE
|
||||||
|
|
||||||
MSG_DR
|
MSG_DR
|
||||||
DB "Reg[0x"
|
DB "Reg[0x"
|
||||||
MSG_DR_RN
|
MSG_DR_RN
|
||||||
@ -247,8 +261,8 @@ MSG_SET_DHCP
|
|||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
; Commands
|
; Commands
|
||||||
; ------------------------------------------------------
|
; ------------------------------------------------------
|
||||||
CMD_QUIT
|
; CMD_QUIT
|
||||||
DB "QUIT\r",0
|
; DB "QUIT\r",0
|
||||||
|
|
||||||
CMD_VERSION
|
CMD_VERSION
|
||||||
DB "AT+GMR\r\n",0
|
DB "AT+GMR\r\n",0
|
||||||
|
|||||||
@ -13,15 +13,18 @@ DEBUG EQU 0
|
|||||||
; Set to 1 to output TRACE messages
|
; Set to 1 to output TRACE messages
|
||||||
TRACE EQU 1
|
TRACE EQU 1
|
||||||
|
|
||||||
|
|
||||||
; Version of EXE file, 1 for DSS 1.70+
|
; Version of EXE file, 1 for DSS 1.70+
|
||||||
EXE_VERSION EQU 0
|
EXE_VERSION EQU 1
|
||||||
|
|
||||||
; Timeout to wait ESP response
|
; Timeout to wait ESP response
|
||||||
DEFAULT_TIMEOUT EQU 2000
|
DEFAULT_TIMEOUT EQU 2000
|
||||||
|
|
||||||
|
DEFDEVICE SPRINTER, 0x4000, 256, 0,1,2,3
|
||||||
|
|
||||||
SLDOPT COMMENT WPMEM, LOGPOINT, ASSERTION
|
SLDOPT COMMENT WPMEM, LOGPOINT, ASSERTION
|
||||||
|
|
||||||
DEVICE NOSLOT64K
|
DEVICE SPRINTER ;NOSLOT64K
|
||||||
|
|
||||||
IF DEBUG == 1
|
IF DEBUG == 1
|
||||||
INCLUDE "dss.asm"
|
INCLUDE "dss.asm"
|
||||||
@ -32,7 +35,7 @@ DEFAULT_TIMEOUT EQU 2000
|
|||||||
|
|
||||||
INCLUDE "macro.inc"
|
INCLUDE "macro.inc"
|
||||||
INCLUDE "dss.inc"
|
INCLUDE "dss.inc"
|
||||||
INCLUDE "sprinter.inc"
|
;INCLUDE "sprinter.inc"
|
||||||
|
|
||||||
MODULE MAIN
|
MODULE MAIN
|
||||||
|
|
||||||
@ -66,28 +69,27 @@ START
|
|||||||
|
|
||||||
CALL ISA.ISA_RESET
|
CALL ISA.ISA_RESET
|
||||||
|
|
||||||
CALL WCOMMON.INIT_VMODE
|
CALL @WCOMMON.INIT_VMODE
|
||||||
|
|
||||||
PRINTLN MSG_START
|
PRINTLN MSG_START
|
||||||
|
|
||||||
CALL WCOMMON.FIND_SWF
|
CALL @WCOMMON.FIND_SWF
|
||||||
|
|
||||||
PRINTLN WCOMMON.MSG_UART_INIT
|
PRINTLN WCOMMON.MSG_UART_INIT
|
||||||
CALL WIFI.UART_INIT
|
CALL @WIFI.UART_INIT
|
||||||
|
|
||||||
PRINTLN WCOMMON.MSG_ESP_RESET
|
PRINTLN WCOMMON.MSG_ESP_RESET
|
||||||
CALL WIFI.ESP_RESET
|
CALL @WIFI.ESP_RESET
|
||||||
|
|
||||||
CALL WCOMMON.INIT_ESP
|
CALL @WCOMMON.INIT_ESP
|
||||||
|
|
||||||
PRINTLN MSG_HLP
|
PRINTLN MSG_HLP
|
||||||
|
|
||||||
CALL WIFI.UART_EMPTY_RS
|
CALL @WIFI.UART_EMPTY_RS
|
||||||
|
|
||||||
MAIN_LOOP
|
MAIN_LOOP
|
||||||
; handle key pressed
|
; handle key pressed
|
||||||
LD C,DSS_SCANKEY
|
DSS_EXEC DSS_SCANKEY
|
||||||
RST DSS
|
|
||||||
JP Z,HANDLE_RECEIVE ; if no key pressed
|
JP Z,HANDLE_RECEIVE ; if no key pressed
|
||||||
LD A,D
|
LD A,D
|
||||||
CP 0xAB
|
CP 0xAB
|
||||||
@ -114,14 +116,14 @@ CHK_PRINTABLE
|
|||||||
|
|
||||||
; transmitt symbol
|
; transmitt symbol
|
||||||
TX_SYMBOL
|
TX_SYMBOL
|
||||||
CALL WIFI.UART_TX_BYTE
|
CALL @WIFI.UART_TX_BYTE
|
||||||
JP C,TX_WARN
|
JP C,TX_WARN
|
||||||
LD A, E
|
LD A, E
|
||||||
CP CR
|
CP CR
|
||||||
JR NZ,HANDLE_RECEIVE
|
JR NZ,HANDLE_RECEIVE
|
||||||
; Transmitt LF after CR
|
; Transmitt LF after CR
|
||||||
LD E,LF
|
LD E,LF
|
||||||
CALL WIFI.UART_TX_BYTE
|
CALL @WIFI.UART_TX_BYTE
|
||||||
JP C,TX_WARN
|
JP C,TX_WARN
|
||||||
|
|
||||||
; check receiver and handle received bytes
|
; check receiver and handle received bytes
|
||||||
@ -159,13 +161,13 @@ CHK_1F
|
|||||||
CHECK_FOR_END
|
CHECK_FOR_END
|
||||||
; LD A,(Q_POS)
|
; LD A,(Q_POS)
|
||||||
; CP 5
|
; CP 5
|
||||||
; JP Z, OK_EXIT
|
; JP Z, OK_EXITDEFDEVICE <deviceid>, <slot_size $100..$10000>, <page_count 1..1024>[, <slot_0_initial_page>[, ...]]
|
||||||
JP MAIN_LOOP
|
JP MAIN_LOOP
|
||||||
|
|
||||||
RX_WARN
|
RX_WARN
|
||||||
LD C,A
|
LD C,A
|
||||||
LD DE,MSG_LSR_VALUE
|
LD DE,MSG_LSR_VALUE
|
||||||
CALL UTIL.HEXB
|
CALL @UTIL.HEXB
|
||||||
PRINTLN MSG_RX_ERROR
|
PRINTLN MSG_RX_ERROR
|
||||||
CALL WIFI.UART_EMPTY_RS
|
CALL WIFI.UART_EMPTY_RS
|
||||||
LD HL,RX_ERR
|
LD HL,RX_ERR
|
||||||
@ -186,8 +188,7 @@ TX_WARN
|
|||||||
|
|
||||||
PUT_A_CHAR
|
PUT_A_CHAR
|
||||||
PUSH BC,DE
|
PUSH BC,DE
|
||||||
LD C,DSS_PUTCHAR
|
DSS_EXEC DSS_PUTCHAR
|
||||||
RST DSS
|
|
||||||
POP DE,BC
|
POP DE,BC
|
||||||
RET
|
RET
|
||||||
|
|
||||||
@ -246,7 +247,7 @@ BUFF_TEST1 DS RS_BUFF_SIZE,0
|
|||||||
ENDMODULE
|
ENDMODULE
|
||||||
|
|
||||||
INCLUDE "wcommon.asm"
|
INCLUDE "wcommon.asm"
|
||||||
INCLUDE "util.asm"
|
;INCLUDE "util.asm"
|
||||||
INCLUDE "isa.asm"
|
INCLUDE "isa.asm"
|
||||||
INCLUDE "esplib.asm"
|
INCLUDE "esplib.asm"
|
||||||
|
|
||||||
|
|||||||
385
sources/DSS/wtftp.asm
Normal file
385
sources/DSS/wtftp.asm
Normal file
@ -0,0 +1,385 @@
|
|||||||
|
; ======================================================
|
||||||
|
; WTFTP client for trivial file transfer protocol
|
||||||
|
; for Sprinter-WiFi ISA Card
|
||||||
|
; By Roman Boykov. Copyright (c) 2024
|
||||||
|
; https://github.com/romychs
|
||||||
|
; License: BSD 3-Clause
|
||||||
|
; ======================================================
|
||||||
|
|
||||||
|
; Set to 1 to turn debug ON with DeZog VSCode plugin
|
||||||
|
; Set to 0 to compile .EXE
|
||||||
|
DEBUG EQU 1
|
||||||
|
|
||||||
|
; Set to 1 to output TRACE messages
|
||||||
|
TRACE EQU 1
|
||||||
|
|
||||||
|
|
||||||
|
WM_DOWNLOAD EQU 0
|
||||||
|
|
||||||
|
WM_UPLOAD EQU 1
|
||||||
|
|
||||||
|
|
||||||
|
; Version of EXE file, 1 for DSS 1.70+
|
||||||
|
EXE_VERSION EQU 1
|
||||||
|
|
||||||
|
; Timeout to wait ESP response
|
||||||
|
DEFAULT_TIMEOUT EQU 2000
|
||||||
|
|
||||||
|
DEFDEVICE SPRINTER, 0x4000, 256, 0,1,2,3
|
||||||
|
|
||||||
|
SLDOPT COMMENT WPMEM, LOGPOINT, ASSERTION
|
||||||
|
|
||||||
|
DEVICE SPRINTER ;NOSLOT64K
|
||||||
|
|
||||||
|
IF DEBUG == 1
|
||||||
|
INCLUDE "dss.asm"
|
||||||
|
DB 0
|
||||||
|
ALIGN 16384, 0
|
||||||
|
DS 0x80, 0
|
||||||
|
ENDIF
|
||||||
|
|
||||||
|
INCLUDE "macro.inc"
|
||||||
|
INCLUDE "dss.inc"
|
||||||
|
;INCLUDE "sprinter.inc"
|
||||||
|
|
||||||
|
MODULE MAIN
|
||||||
|
|
||||||
|
ORG 0x8080
|
||||||
|
; ------------------------------------------------------
|
||||||
|
EXE_HEADER
|
||||||
|
DB "EXE"
|
||||||
|
DB EXE_VERSION ; EXE Version
|
||||||
|
DW 0x0080 ; Code offset
|
||||||
|
DW 0
|
||||||
|
DW 0 ; Primary loader size
|
||||||
|
DW 0 ; Reserved
|
||||||
|
DW 0
|
||||||
|
DW 0
|
||||||
|
DW START ; Loading Address
|
||||||
|
DW START ; Entry Point
|
||||||
|
DW STACK_TOP ; Stack address
|
||||||
|
DS 106, 0 ; Reserved
|
||||||
|
|
||||||
|
ORG 0x8100
|
||||||
|
@STACK_TOP
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
START
|
||||||
|
|
||||||
|
IF DEBUG == 1
|
||||||
|
LD IX,CMD_LINE_TFTP_D
|
||||||
|
LD SP, STACK_TOP
|
||||||
|
JP MAIN_LOOP
|
||||||
|
ENDIF
|
||||||
|
|
||||||
|
CALL PARSE_CMD_LINE
|
||||||
|
|
||||||
|
CALL OPEN_LOCAL_FILE
|
||||||
|
|
||||||
|
CALL ISA.ISA_RESET
|
||||||
|
|
||||||
|
CALL @WCOMMON.INIT_VMODE
|
||||||
|
|
||||||
|
PRINTLN MSG_START
|
||||||
|
|
||||||
|
CALL @WCOMMON.FIND_SWF
|
||||||
|
|
||||||
|
PRINTLN WCOMMON.MSG_UART_INIT
|
||||||
|
CALL @WIFI.UART_INIT
|
||||||
|
|
||||||
|
PRINTLN WCOMMON.MSG_ESP_RESET
|
||||||
|
CALL @WIFI.ESP_RESET
|
||||||
|
|
||||||
|
CALL @WCOMMON.INIT_ESP
|
||||||
|
|
||||||
|
PRINTLN MSG_HLP
|
||||||
|
|
||||||
|
CALL @WIFI.UART_EMPTY_RS
|
||||||
|
|
||||||
|
MAIN_LOOP
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Do Some
|
||||||
|
; ------------------------------------------------------
|
||||||
|
|
||||||
|
OK_EXIT
|
||||||
|
LD B,0
|
||||||
|
JP WCOMMON.EXIT
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; IX - points to cmd line
|
||||||
|
; ------------------------------------------------------
|
||||||
|
PARSE_CMD_LINE
|
||||||
|
PUSH IX
|
||||||
|
POP HL
|
||||||
|
LD A,(HL)
|
||||||
|
OR A
|
||||||
|
JR Z, OUT_USAGE_MSG
|
||||||
|
CALL SKIP_SPACES
|
||||||
|
|
||||||
|
|
||||||
|
; check first parameter for tftp url pattern
|
||||||
|
LD DE,TFTF_START
|
||||||
|
CALL @UTIL.STARTSWITH
|
||||||
|
JR NZ,.PLC_UPLOAD
|
||||||
|
|
||||||
|
; Work Mode "Download"
|
||||||
|
|
||||||
|
; handle parameter URL
|
||||||
|
LD DE,0x0007
|
||||||
|
ADD HL,DE
|
||||||
|
CALL GET_SRV_PARAMS
|
||||||
|
CALL SKIP_SPACES
|
||||||
|
|
||||||
|
; handle lfn
|
||||||
|
CALL GET_LFN
|
||||||
|
RET
|
||||||
|
|
||||||
|
.PLC_UPLOAD
|
||||||
|
; Work mode "Upload"
|
||||||
|
LD A, WM_UPLOAD
|
||||||
|
LD (WORK_MODE),A
|
||||||
|
|
||||||
|
CALL GET_LFN
|
||||||
|
CALL SKIP_SPACES
|
||||||
|
CALL GET_SRV_PARAMS
|
||||||
|
|
||||||
|
RET
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
OUT_ERR_CMD_MSG
|
||||||
|
PRINTLN MSG_ERR_CMD
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
OUT_USAGE_MSG
|
||||||
|
PRINTLN MSG_HLP
|
||||||
|
JP OK_EXIT
|
||||||
|
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Move srv name and port number from (HL) to (DE)
|
||||||
|
; ------------------------------------------------------
|
||||||
|
GET_SRV_PARAMS
|
||||||
|
PUSH BC,DE
|
||||||
|
LD DE,SRV_NAME
|
||||||
|
.GSN_NEXT
|
||||||
|
LD A,(HL)
|
||||||
|
OR A ; end of url?
|
||||||
|
JR Z,.GSN_END
|
||||||
|
CP '/' ; end of server name?
|
||||||
|
JR Z,.GSN_END
|
||||||
|
CP ':' ; end of server name and has port?
|
||||||
|
JR Z,.GSN_PORT
|
||||||
|
LD (DE), A ; move and get next
|
||||||
|
INC HL
|
||||||
|
INC DE
|
||||||
|
JR .GSN_NEXT
|
||||||
|
; has port number
|
||||||
|
.GSN_PORT
|
||||||
|
LD DE,SRV_PORT
|
||||||
|
LD B,6
|
||||||
|
.GSNP_NXT
|
||||||
|
INC HL
|
||||||
|
LD A,(HL)
|
||||||
|
CP A,'/' ; end slash
|
||||||
|
JR .GSN_EN
|
||||||
|
CP A,'0'
|
||||||
|
JP M,.GSN_EPN
|
||||||
|
CP A,'9' ; >'9'?
|
||||||
|
JP P,.GSN_EPN
|
||||||
|
LD (DE),A
|
||||||
|
INC DE
|
||||||
|
DEC B
|
||||||
|
JR Z,.GSN_EPN ; too long number
|
||||||
|
JR .GSNP_NXT
|
||||||
|
; end of numbers
|
||||||
|
|
||||||
|
|
||||||
|
.GSN_EPN
|
||||||
|
PRINTLN MSG_ERR_PORT
|
||||||
|
JP OUT_USAGE_MSG
|
||||||
|
|
||||||
|
.GSN_EN
|
||||||
|
LD DE,SRV_PORT
|
||||||
|
LD A,(DE)
|
||||||
|
OR A ; ':/' - no port number specified
|
||||||
|
JR Z,.GSN_EPN
|
||||||
|
PUSH HL
|
||||||
|
CALL @UTIL.ATOU
|
||||||
|
LD (SRV_PORT),HL
|
||||||
|
POP HL
|
||||||
|
|
||||||
|
.GSN_END
|
||||||
|
; get file name from url
|
||||||
|
LD DE,REM_FILE
|
||||||
|
LD B,127
|
||||||
|
.GDNF_NXT
|
||||||
|
INC HL
|
||||||
|
LD A,(HL)
|
||||||
|
OR A
|
||||||
|
JR Z,.GDNF_END
|
||||||
|
LD (DE),A
|
||||||
|
INC DE
|
||||||
|
DEC B
|
||||||
|
JR NZ,.GDNF_NXT
|
||||||
|
JR .GDNF_ERR ; file name too long
|
||||||
|
; check file name is not empty
|
||||||
|
.GDNF_END
|
||||||
|
LD DE,REM_FILE
|
||||||
|
LD A,(DE)
|
||||||
|
OR A
|
||||||
|
JR NZ,.GSN_RET
|
||||||
|
; out error about invalid file name
|
||||||
|
.GDNF_ERR
|
||||||
|
PRINTLN MSG_ERR_RFN
|
||||||
|
JP OUT_USAGE_MSG
|
||||||
|
.GSN_RET
|
||||||
|
POP DE,BC
|
||||||
|
RET
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Get local file name from command string
|
||||||
|
;
|
||||||
|
; ------------------------------------------------------
|
||||||
|
GET_LFN
|
||||||
|
PUSH BC,DE
|
||||||
|
|
||||||
|
XOR B
|
||||||
|
LD DE,LOC_FILE
|
||||||
|
LD A,(HL)
|
||||||
|
OR A
|
||||||
|
JR Z,.GLF_E
|
||||||
|
CP ' '
|
||||||
|
JR Z,.GLF_E
|
||||||
|
; CP "\\"
|
||||||
|
; CALL Z,.GLF_SET_DIR
|
||||||
|
; CP ":"
|
||||||
|
; CALL Z,.GLF_SET_DIR
|
||||||
|
CP 0x21
|
||||||
|
JP M,.GLF_IFN
|
||||||
|
CP '*'
|
||||||
|
JP Z,.GLF_IFN
|
||||||
|
LD (DE),A
|
||||||
|
|
||||||
|
.GLF_E
|
||||||
|
|
||||||
|
POP DE,BC
|
||||||
|
RET
|
||||||
|
|
||||||
|
; set flag to not add current dir
|
||||||
|
.GLF_SET_DIR
|
||||||
|
LD B,1
|
||||||
|
RET
|
||||||
|
|
||||||
|
; Illegal file name
|
||||||
|
.GLF_IFN
|
||||||
|
PRINTLN MSG_ERR_LFN
|
||||||
|
JP OUT_USAGE_MSG
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Open local file for upload or download
|
||||||
|
; RO - for upload
|
||||||
|
; WR - for download
|
||||||
|
; ------------------------------------------------------
|
||||||
|
OPEN_LOCAL_FILE
|
||||||
|
LD A, (WORK_MODE)
|
||||||
|
CP WM_UPLOAD
|
||||||
|
|
||||||
|
RET
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Skip spaces at start of zero ended string
|
||||||
|
; Inp: HL - pointer to string
|
||||||
|
; Out: HL - points to first non space symbol
|
||||||
|
; ------------------------------------------------------
|
||||||
|
SKIP_SPACES
|
||||||
|
LD A, (HL)
|
||||||
|
OR A
|
||||||
|
RET Z
|
||||||
|
CP 0x21
|
||||||
|
RET P
|
||||||
|
INC HL
|
||||||
|
JR SKIP_SPACES
|
||||||
|
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Custom messages
|
||||||
|
; ------------------------------------------------------
|
||||||
|
|
||||||
|
MSG_START
|
||||||
|
DB "TFTP client for Sprinter-WiFi by Sprinter Team. v1.0 beta1, ", __DATE__, "\r\n"Z
|
||||||
|
|
||||||
|
MSG_ERR_CMD
|
||||||
|
DB "Invalid command line parameters!\r\n"Z
|
||||||
|
|
||||||
|
MSG_HLP
|
||||||
|
DB "\r\nUse: wtftp.exe tftp://server[:port]/filename filename - to download file from server;\r\n"
|
||||||
|
DB "\twtftp.exe filename tftp://server[:port]/filename - to upload file to server.\r\n"Z
|
||||||
|
|
||||||
|
MSG_TX_ERROR
|
||||||
|
DB "Transmitter not ready"Z
|
||||||
|
|
||||||
|
MSG_RX_ERROR
|
||||||
|
DB "Receiver error LSR: 0x"
|
||||||
|
MSG_LSR_VALUE
|
||||||
|
DB "xx"Z
|
||||||
|
|
||||||
|
MSG_MANY_RX_ERROR
|
||||||
|
DB "Too many receiver errors!"Z
|
||||||
|
|
||||||
|
MSG_ERR_PORT
|
||||||
|
DB "Invalid UDP port in URL, will be number 1..65535"Z
|
||||||
|
|
||||||
|
MSG_ERR_RFN
|
||||||
|
DB "Remote file name not specified in URL, or too long!"Z
|
||||||
|
|
||||||
|
MSG_ERR_LFN
|
||||||
|
DB "Invalid local file name!"Z
|
||||||
|
|
||||||
|
; Start of tftf URL
|
||||||
|
TFTF_START
|
||||||
|
DB "tftp://"Z
|
||||||
|
|
||||||
|
|
||||||
|
; Work Mode
|
||||||
|
WORK_MODE
|
||||||
|
DB WM_DOWNLOAD
|
||||||
|
|
||||||
|
; Name/IP of the tftp server
|
||||||
|
SRV_NAME
|
||||||
|
DS 128,0
|
||||||
|
|
||||||
|
; UDP port of the tftp server
|
||||||
|
SRV_PORT
|
||||||
|
DB 69,0,0,0,0,0 ; udp port number 0..65535
|
||||||
|
|
||||||
|
; Name of the source file
|
||||||
|
REM_FILE
|
||||||
|
DS 128,0
|
||||||
|
|
||||||
|
LOC_FILE
|
||||||
|
DS 128,0
|
||||||
|
|
||||||
|
LOC_FH
|
||||||
|
DW 0
|
||||||
|
|
||||||
|
; ------------------------------------------------------
|
||||||
|
; Custom commands
|
||||||
|
; ------------------------------------------------------
|
||||||
|
RX_ERR
|
||||||
|
DB 0
|
||||||
|
|
||||||
|
IF DEBUG == 1
|
||||||
|
CMD_TEST1 DB "ATE0\r\n"Z
|
||||||
|
BUFF_TEST1 DS RS_BUFF_SIZE,0
|
||||||
|
ENDIF
|
||||||
|
|
||||||
|
ENDMODULE
|
||||||
|
|
||||||
|
INCLUDE "wcommon.asm"
|
||||||
|
;INCLUDE "util.asm"
|
||||||
|
INCLUDE "isa.asm"
|
||||||
|
INCLUDE "esplib.asm"
|
||||||
|
|
||||||
|
|
||||||
|
END MAIN.START
|
||||||
Loading…
Reference in New Issue
Block a user