166 lines
7.2 KiB
Plaintext
166 lines
7.2 KiB
Plaintext
$Id: INTERWORKING,v 1.2 1999/07/01 18:00:21 he Exp $
|
|
|
|
The following classes of inter-working problems have been identified
|
|
====================================================================
|
|
|
|
Some clients rely on a particular order of file header parameters
|
|
appearing in file headers or description files resulting from an
|
|
extended format directory request. In particular, they fail when
|
|
optional parameters appear before the mandatory ones.
|
|
The current eftp4linux implementation works around this (without violating
|
|
protocol specifications) by providing
|
|
the mandatory parameters at the front of the file header or directory
|
|
records and in the same order as appearing in ETS 300 383 (which
|
|
does, however, not require for a particular order).
|
|
|
|
FileHeaderOrder (!) client depends on file attribute parameters
|
|
appearing in a particular order inside file headers.
|
|
|
|
XDirOrder (!) client depends on file attribute parameters
|
|
appearing in a particular order inside
|
|
description file records resulting from an
|
|
extended format directory request.
|
|
|
|
|
|
Clients can ask the server for a list of files or subdirectories
|
|
present the current working directory (by the T-DIR or S-LIST
|
|
primitives). The server responds by sending back a file containing
|
|
so-called transfer names (those are used to identify the files,
|
|
but are not necessarily equal to the file
|
|
names) or a list of subdirectory (`sub-filestore') names. Now,
|
|
if the client wants to load a certain file or change to a certain
|
|
directory, they need to send a request containing the desired transfer
|
|
name or sub-filestore name. However, several clients don't use the
|
|
transfer name as received from the server:
|
|
|
|
TransNameCases (+) upper/lower case letters are not preserved in
|
|
transfer names
|
|
DirNameCases (+) upper/lower case are not preserved in
|
|
sub-filestore names
|
|
DirNameSlash (+) client replaces slashes by backslashes in
|
|
directory names
|
|
|
|
The eftp4linux server can work around those, but such workarounds
|
|
impose additional restrictions. For example, if a there were two
|
|
files README and ReadMe, with the work around active you cannot access
|
|
both files any longer even when your clients is compliant with the
|
|
protocol specification. Thus, the corresponding workarounds are not
|
|
turned on by default, you need to explicitly request for them
|
|
(currently, by prepending an '+' character in front of your user id).
|
|
|
|
TransNameTruncated the clients truncates parts of the transfer name
|
|
(usually at the part until the last '/' character)
|
|
DirNameTruncated (!) the clients truncates parts of the directory name
|
|
(usually at the part until the last '/' character)
|
|
|
|
Truncating the transfer name at '/' has caused interworking problems
|
|
with eftp4liux version 0.0.2 because that eftp4linux implementation
|
|
inserted backslashes in filenames which are longer that 12 characters
|
|
As a result, clients suffering from this bug could not access files
|
|
with long file names.
|
|
|
|
ETS 300 383 refers to ETS 300 075 4.4.4,
|
|
which requires transfer names to be composed by '/' separated
|
|
words (each word not longer than 12 characters). By inserting '/'
|
|
characters, the resulting transfer name becomes compliant with
|
|
ETS 300 075 4.4.4, but the real originating file name is still
|
|
guessible by a human reader (at least much better than something
|
|
like "~FILE~.124"). Unfortunately, many clients have more problems
|
|
with compliant transfer names than with non-compliant names.
|
|
eftp4linux version 0.0.3 uses a database for mapping
|
|
between transfer names an file names, this will hopefully solve
|
|
that particual interwoking problem.
|
|
|
|
Truncating a directory name to its basename does not hurt so much
|
|
because the basename is sufficient for identifying a directory inside the
|
|
current working directory. (This will, however, currently not work if the
|
|
directory name is a symlink).
|
|
|
|
Keep in mind that, even when your client's protocol implementation is
|
|
able to access long file names, it might fail to load them because if
|
|
your operating system does not support long file names.
|
|
|
|
x suffers from the problem
|
|
+ suffers from the problem, but frequently works when compatibility mode
|
|
("+userid") is activated.
|
|
! suffers from the problem, but frequently that does not matter
|
|
because current eftp4linux frequently can work around this without
|
|
implying other restrictions.
|
|
- suffers from the problem, but that does not matter any more
|
|
because the current eftp4linux generally works around this.
|
|
|
|
|
|
|
|
FileHeaderOrder
|
|
| XDirOrder
|
|
| | TransNameCases
|
|
| | | DirNameCases
|
|
| | | | DirNameSlash
|
|
| | | | | TransNameTruncated
|
|
| | | | | | DirNameTruncated
|
|
|
|
eftp4linux client :-)
|
|
|
|
TELES.Fix 2.5
|
|
TELES.Fix 4.0 - x
|
|
TELES.Fix 6.0
|
|
|
|
AVM/FRITZ - + +
|
|
|
|
RVS-COM x !
|
|
BIANCA ISDN
|
|
|
|
(As BIANCA supports unix, the developers might have been aware of the
|
|
case sensitiveness problems. But unfortunately, I don't have any
|
|
logs from BIANCA sessions where a long name file was tried to be
|
|
downloaded.
|
|
|
|
|
|
If blank, then nothing is known because, i.e.,
|
|
- I received no connections attempting to use the corresponding feature
|
|
- I received such attempts only after the corresponding workarounds
|
|
were already implemented
|
|
- the client does not support this feature at all
|
|
- it works as it should work
|
|
|
|
Other observed connection attempts which were rejected due to wrong
|
|
user IDs (not "ftp" or "+ftp")
|
|
|
|
TELES.FIX 3.07
|
|
TELES.Fix 5.0
|
|
TELES.Fix 6.01NT
|
|
|
|
|
|
|
|
There also seem to be inter-working problems related the ISO 8208
|
|
(X.25 DTE-DTE) protocol which is used in the lower layers by Eurofile.
|
|
(This is usually implemented by the CAPI driver)
|
|
|
|
Some broken clients (i.e. those based on the xxxx isdn toolbox) miss
|
|
to pass mandatory X.25/ISO-8208 parameters with the X.25 call request
|
|
(CAPI Connect-B3-Request). If the Capi driver is also buggy and does
|
|
not detect and correct this, a misformatted, X.25 packet
|
|
(violating X.25 specs) is send. Such packets currently confuse the
|
|
Linux X.25 Layer. This has been observed with clients based on the
|
|
CSD isdn toolbox. Similar symptoms observed with certain RVS clients
|
|
might be caused by the same problem.
|
|
|
|
|
|
There is a kernel patch, ix25-2.1.128.diff, which detects the misformatted
|
|
packets and clears the call as required by the X.25 specification.
|
|
However, this will not fix the interworking problem. For this,
|
|
activate (uncomment) the #define at the last line of
|
|
include/net/x25.h. This partially helps, but is not bullet proof.
|
|
It has been reported to result in hangs when the buggy clients connect
|
|
and try to download files. For interworking with such clients, try
|
|
setting the facilities.winsize_in and facilities.winsize_out variable
|
|
in eftd.c to 1.
|
|
|
|
|
|
Miscc/open questions
|
|
|
|
Should the .. directory be present in the file generated in response
|
|
to an [S]LIST request? AVM/Fritz clients generate this entry locally
|
|
which causes .. to be displayed twice if the server also included a ..
|
|
entry in the SLIST response file.
|