From cda43f668846cedd2fb45756d1366b22bc60c177 Mon Sep 17 00:00:00 2001 From: djm Date: Sun, 29 Jun 2008 14:04:57 +0000 Subject: [PATCH] - djm@cvs.openbsd.org 2008/06/28 07:25:07 [PROTOCOL] spelling fixes --- ChangeLog | 3 +++ PROTOCOL | 14 +++++++------- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7b613d39..548bb856 100644 --- a/ChangeLog +++ b/ChangeLog @@ -31,6 +31,9 @@ - jmc@cvs.openbsd.org 2008/06/26 21:11:46 [ssh.1] add VisualHostKey to the list of options listed in -o; + - djm@cvs.openbsd.org 2008/06/28 07:25:07 + [PROTOCOL] + spelling fixes 20080628 - (djm) [RFC.nroff contrib/cygwin/Makefile contrib/suse/openssh.spec] diff --git a/PROTOCOL b/PROTOCOL index 08b16dc1..64b194cd 100644 --- a/PROTOCOL +++ b/PROTOCOL @@ -86,9 +86,9 @@ Note that this is not a general defence against compromised clients 5. connection: Tunnel forward extension "tun@openssh.com" -OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com" +OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" channel type. This channel type supports forwarding of network packets -with datagram boundaries entact between endpoints equipped with +with datagram boundaries intact between endpoints equipped with interfaces like the BSD tun(4) device. Tunnel forwarding channels are requested by the client with the following packet: @@ -142,13 +142,13 @@ The contents of the "data" field for layer 3 packets is: uint32 packet length byte[packet length] frame -The "frame" field contains an IEEE 802.3 ethernet frame, including +The "frame" field contains an IEEE 802.3 Ethernet frame, including header. 6. sftp: Reversal of arguments to SSH_FXP_SYMLINK When OpenSSH's sftp-server was implemented, the order of the arguments -to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately, +to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, the reversal was not noticed until the server was widely deployed. Since fixing this to follow the specification would cause incompatibility, the current order was retained. For correct operation, clients should send @@ -177,7 +177,7 @@ Each extension reports its integer version number as an ASCII encoded string, e.g. "1". The version will be incremented if the extension is ever changed in an incompatible way. The server MAY advertise the same extension with multiple versions (though this is unlikely). Clients MUST -check the version number before attemping to use the extension. +check the version number before attempting to use the extension. 8. sftp: Extension request "posix-rename@openssh.com" @@ -207,7 +207,7 @@ pathname, and is formatted as follows: string "statvfs@openssh.com" string path -The "fstatvfs@openssh.com" operates on an open filehandle: +The "fstatvfs@openssh.com" operates on an open file handle: uint32 id string "fstatvfs@openssh.com" @@ -237,4 +237,4 @@ The values of the f_flag bitmask are as follows: This extension is advertised in the SSH_FXP_VERSION hello with version "2". -$OpenBSD: PROTOCOL,v 1.7 2008/06/12 05:15:41 djm Exp $ +$OpenBSD: PROTOCOL,v 1.8 2008/06/28 07:25:07 djm Exp $ -- 2.45.2