$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.