diff --git a/eurofile/doc/FAQ b/eurofile/doc/FAQ new file mode 100644 index 00000000..6cc1a32b --- /dev/null +++ b/eurofile/doc/FAQ @@ -0,0 +1,30 @@ +$Id: FAQ,v 1.1 1999/06/30 16:50:57 he Exp $ + +QUESTION: How can I control the amount of debugging output? +========= + +ANSWER: + +eftd.c and eftp.c contain set a global variable tdu_stderr_mask. +Locate this and change the comment characters (/* .. */). For only +logging Error events, the final active statement should be + + tdu_stderr_mask = TDU_LOG_ERR | TDU_LOG_IER; + +To remove isdnlog output to stderr, you can also comment out the +'tdu_open_isdtlog()' statement. + +The eftd server now also allows to +control the amount of debugging output via command line arguments, +refer to the eftd(8) man page for further info. + + +QUESTION: I don't want anonymous users to dial in without a MSN +========= +If a client without a MSN dials in, the ISDN number 0 is assumed. +With the line "guestservers 1* 2* 3* 4* 5* 6* 7* 8* 9*" in +/etc/isdn/eftaccess connections with ISDN numbers beginning with +"0" are refused. Don't forget the option "-a" for eftd to make him +the file /etc/isdn/eftaccess used. +(What's about international connections then? Do they begin with "0"? +I dont'n know, never had one...) diff --git a/eurofile/doc/INTERWORKING b/eurofile/doc/INTERWORKING new file mode 100644 index 00000000..d24176ff --- /dev/null +++ b/eurofile/doc/INTERWORKING @@ -0,0 +1,166 @@ +$Id: INTERWORKING,v 1.1 1999/06/30 16:50:58 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 nameed 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. + diff --git a/eurofile/doc/INTERWORKING.de b/eurofile/doc/INTERWORKING.de new file mode 100644 index 00000000..58d3d9af --- /dev/null +++ b/eurofile/doc/INTERWORKING.de @@ -0,0 +1,15 @@ +$Id: INTERWORKING.de,v 1.1 1999/06/30 16:50:58 he Exp $ + +Bisher ist Interworking der 0.0.2-Version mit den folgenden +Protokollimplementierungen offenbar (teilweise) erfolgreich gewesen. + +- mit der eigenen (Linux) EUROFile Implementierung als Gegenstelle +- AVM/Fritz +- TELES +- BIANCA ISDN +- RVS-COM Lite Version 1.22 + +(wobei trotzdem Probleme wie unten beschrieben auftreten können, +genaueres steht im File INTERWORKING in der Distribution) + + diff --git a/eurofile/doc/PROBLEME.eftd b/eurofile/doc/PROBLEME.eftd new file mode 100644 index 00000000..fc1c72d7 --- /dev/null +++ b/eurofile/doc/PROBLEME.eftd @@ -0,0 +1,90 @@ +$Id: PROBLEME.eftd,v 1.1 1999/06/30 16:50:59 he Exp $ + +Die Implementierung ist noch nicht komplett, folgende Probleme sind +bekannt: + +- Navigation (so heißt bei EUROfile alles, was mit Directories zu tun hat) + ist noch nicht vollständig protokollkonform unterstützt. Hier sind + zuvor noch einige offene Fragen zu klären. (s.u.) + Zur Zeit wird immer der durch realpath(3) kanonisierte Directory-Pfad als + Filestore-Name benutzt. Dies kann dazu führen, daß Filestorenamen + mehrfach auftreten, wenn sie unter verschiedenen Namen (symlinks) + erreichbar sind (oder gewisse Links ganz ausgeblendet werden). + Es wird auch noch keine global eindeutige Information über die + Anordnung der Filestores untereinander ("Filestore Reference") + erzeugt. Das könnte zu Problemen führen, wenn ein besonders + intelligenter Client versucht, die Directory-Struktur des Servers + local nachzubilden. + +- Bei einigen Clients wurden Probleme mit der Groß/Klein-schreibung + von Transfernamen beobachtet. Manche Clients benutzen sogar für + die Übertragung in der einen Richtung grundsätzlich Transfernamen in + Großbuchstaben, für die Gegenrichtung in Kleinbuchstaben. Da der Linux Server + die Transfernamen als Dateinamem (und nach Unix-Manier case sensitive) + interpretiert, können solche Clients ihre eigenen, gerade geschriebenen + Dateien nicht wieder zurücklesen. Nach den EUROFile Normen (ETS 300 383 / + ETS 300 075) sollten Transfernamen case-sensitive sein (zumindest steht + da nichts Gegenteiliges). Daher betrachte ich dieses Problem eigentlich + nicht als meines, bis mich jemand eines besseren belehrt. Seltsamerweise + habe ich auch schon connections von Clients gleicher Herstller gehabt, die + die Groß/Kleinschreibung konsistent benutzt haben. Daher vermute ich, daß das + Problem im User Interface der Software begründet ist und sich daher die + DOS, Win3.1, und Win95 Versionen oder gar dieselbe eft + Client-Version unter verschieden Windows-Version möglicherweise + unterschiedlich verhalten. + + Wer einen Client mit solchen Problemen hat, kann einen + Kompatibilitätsmodus aktivieren, indem er dem Login-Namen ein + '+'-Zeichen voranstellt (z.B. userid "+ftp" statt "ftp"). Dann + wird Groß/Kleinschreibung bei Dateinamen ignoriert, + Directory-Prefixe werden stets in Kleinbuchstaben konvertiert. + Damit sind natürlich gewisse Dateien mit dem Eurofile-Protokoll + nicht mehr zugreifbar. + +- Die meisten Clients scheinen offenbar, wenn man keinen login Namen + angibt, irgendeinen Default Namen (z.B wurde "No Name" bei Teles + beobachtet) zu verwenden. Das Einloggen geht dann schief, wenn + kein login account mit Namen "No Name" existiert. Um dem + vorzubeugen, solltet ihr grundsätzlich einen login-namen explizit + angeben (und zwar "ftp" bzw. "+ftp" bei anonymem Zugang). + +- Die Datumsübertragung im ETS 300 075 Protokoll ist nicht y2k safe! + +- Die maximale Länge von übertragbaren Dateien ist durch gewisse + Restriktionen im ETS 300 075 Protokoll begrenzt (auf ca 64 MByte bei + üblicher 1k Blockgröße). + + + +Offene Fragen: + +UNIX geht davon aus, daß die Dateistruktur eine gemeinsame Wurzel "/" +hat. Einzelne User haben darin Home-Directories. +EUROFile geht davon aus, daß jeder User einen Default-Filestore +(analog Home-Directory) hat, der gleichzeitig die logische Wurzel +aller erreichbaren Sub-Filestore's (analog Sub-Directories) ist. +Dieser Unterschied schlägt insbesondere bei Dateien zu, die nicht +unterhalb des Home-Directories des Benutzers liegen. +Die offene Frage ist, ob und wie diese unterschiedliche logische Sicht +auf den Dateibaum im Server umgesetzt werden soll. + +Da die meisten Unix-ähnlichen Betriebssysteme Symlinks haben, ist +dasselbe Directory unter Umständen unter mehreren verschiedenen Namen +erreichbar, so daß die durch Datei/Directory-Namen beschriebene Struktur +nicht zwangsläufig eine reine Baumstruktur darstellt. EUROFILE geht +dagegen von einer logisch reinen Baumstruktur aus. +Die offene Frage ist, ob und wie der Server den Zugriff auf +Directories über Symlinks zulassen soll. Der einfachste Weg, eine +logische Baumstruktur für eft zur Verfügung zu stellen, besteht darin, +Symlinks zu Directories einfach auszublenden. Dann kann man natürlich +die ganzen Vorteile, die Symlinks in der Administration bieten, für +Eurofile nicht mehr nutzen (und z.B. bestehende ftp-Archive mit +Symlinks nur eingeschränkt über EUROFile zuganglich machen). +Vielleicht kann man auch die Einschränkungen aus ETS 300 383 +einfach ignorieren, aber das bringt unter Umständen +protokollkonforme Clients durcheinander. Andere Lösungen +(Vorschläge willkommen) erfordern wohl mehr Implementierungsaufwand. + +(Für die detailierte Beschreibung/Analyse der Interworking-Probleme siehe +auch das File INTERWORKING in der Distribution). + diff --git a/eurofile/doc/PROBLEMS-2.1.114 b/eurofile/doc/PROBLEMS-2.1.114 new file mode 100644 index 00000000..a9859428 --- /dev/null +++ b/eurofile/doc/PROBLEMS-2.1.114 @@ -0,0 +1,54 @@ +$Id: PROBLEMS-2.1.114,v 1.1 1999/06/30 16:51:00 he Exp $ + +Known problems observed when using X.25 on top of isdn with kernel 2.1.126 +========================================================================== + +The X.25 PLP implementation was originally designed to be used on top +of a synchronous line (accessed via an X.25 network device driver) +or on top of lan (IEEE 802 LLC type 2). Furthermore, the X.25 +implementation as well as the related isdn4linux extensions are labelled +as "EXPERIMENTAL" code in the kernel source tree. Thus, the X.25 protocol +sometimes doesn't behave as you would expect, in particular when used +on top of isdn. + + +Problems related to isdn drivers: +================================= + +The isdnloop HL driver apparently has problems to re-establish a +connection that has been hung up from the outgoing device. You have to +unload the isdnloop driver after the faked isdn-connection is closed +and insmod it again. With the Hisax driver, this problem is not present. + +When ifconfig'ing isdn network interfaces (with encap x25iface set) down, +"disconnect indication while unconfigured" messages might appear in +the syslog. This does not indicate any problem and can be ignored. + +When establishing the first X.25 connection on a link, there is a +delay of some seconds until the link becomes established. This is only +a performance problem and harmless. Furthermore, this is fixed with +recent isdn4linux versions from the isdn4linux CVS tree. + +Problems related to the X.25 PLP implementation: +================================================ + +isdn B channels are not closed automatically when the X.25 PLP +connection is closed. If you are lucky, your peer does it. Thus, +monitor your isdn connections while using X.25 on top of isdn4linux +(i.e. by watching syslog messages or by an isdn monitor program). +You need to close the B channel connection by hand (using the +"isdnctrl hangup" command) or rely on the isdn network interface's +hangup timeout. The scripts provided with this this test distribution +try to provide workourounds for this. + +Kernels prior to 2.1.125 have a bug in include/linux/x25.h which +has been reported to cause compilation problems on glibc2 systems. + +2.1.127 introduced changes that broke current i4l CVS isdn subsystem. +Until this is fixed, only use cvs isdn with 2.1.126 or older. + + + + + + diff --git a/eurofile/doc/README b/eurofile/doc/README new file mode 100644 index 00000000..e2fe71bd --- /dev/null +++ b/eurofile/doc/README @@ -0,0 +1,6 @@ +$Id: README,v 1.1 1999/06/30 16:51:00 he Exp $ + +For previewing man pages (i.e. efthosts.5), use + +nroff -man efthosts.5 | less + diff --git a/eurofile/doc/README.old b/eurofile/doc/README.old new file mode 100644 index 00000000..698e000e --- /dev/null +++ b/eurofile/doc/README.old @@ -0,0 +1,223 @@ + + +Expert start +============ + +This is an older setup procedure kept for compatibility and expert +users who want to do more with x25 on top of isdn4linux. +(this is no longer supported but as you are an expert user, you might +want to edit the scripts such that it works with this release again). + +Even if you don't use isdn, this might be useful for testing PF_X25 +network applications. The test distribution supports +setting up X.25 connections on top of the isdnloop driver. This allows +you to set up X25 connections between a client and a server application +running on the same machine. There is no physical x25 network +interface needed. This is similar to setting up tcp/ip connections +to the "localhost" IP address. (Using the isdn subsystem for this +might be overkill, but there is currently no other x25 loop device +driver at all). + +A script "ix25test" is provided inside the scripts +directory. That script does all the necessary setups needed for +testing x.25 on top of isdn4linux. You need to edit the script to +account for your local configuration (i.e. your MSN, ISDN-numbers +of your peer, location of utility binaries and kernel sources/modules, +configuration of your isdn HL driver, ...). +You should unload all isdn drivers modules and the x25 module before +calling this script. + +When done, you can just call "ix25test start". However, read the +comments in the script file as well as the remaining part of this +README file and the PROBLEMS.* files before using it. + + +Now the really cool stuff in detail: + +1. Boot your (patched) kernel (see remarks below) + +2. log in as root + +3. Make sure that all isdn and x25 related modules are unloaded. I also + prefer to switch to runlevel 1 (using the command "init 1") when doing + my tests, this will usually unload all isdn drivers as well. + + Call the configuration script: + + ix25test start telnetd 01 + + (In case of problems, issue the command "ix25test stop", fix + the script, and repeat) + +4. switch to another virtual terminal, log in (not as root), and + start the x25 based telnet client. Assuming your x25 based telnet + client resides in x25bin/telnet enter the command + + x25bin/telnet 00 01 + + This will open an x25-based telnet session on top of isdn4linux + to your own machine. The isdnloop HL driver is used for this, thus + no real isdn line is occupied (and no phone bill will result from + this). If it works you should be able to log in, issue some commands + and log out again. + +5. After exiting from the telnet session, switch back to the other + virtual console (where you started the ix25test script) and type + ^C. This should kill the telnetd and shut down the test + configuration again. + + +If this worked well you can try x.25 connections on top of real isdn +connections to your own computer. Similar procedure as above, but +slightly different command arguments: + + +3. ix25test start telnetd 03 + +4. x25bin/telnet 00 03 + +This will establish a real isdn connection on top of hisax to yourself +(your PTT will probably charge you). Please monitor (i.e by watching +syslog messages) the isdn connections during and after your tests. +(Verify that connections are properly released after your tests and +no power dialing or other expensive actions happen during your tests.) + + +If this worked you might try a connection to a remote computer. Find a +partner operates an EUROFILE server and agrees that you connect to it +with this experimental software. + +1. boot the test configuration as above. Alternatively, as you don't need + an x.25 based server on your own machine, "ix25test start" is + sufficient. + +2. Assuming your user name on the eft server is "myname" and your + password is "mypass", switch to the non-root virtual console and type + + eftp 05 myname/mypass + + from the shell's prompt. This will try to connect to the remote + eft server. + +3. type + + dir * + + from the "eftp>" prompt to list the directory of the eft server. + +4. type + + get [] + + from the "eftp>" prompt, where denotes a file name + present on the remote server (such as listed by the previously + issued "dir"-command). This will download that file. + +5. type + + put [] + + to upload a file to the remote server. (This is known not to inter-work + with certain remote eftp servers when used with an unpatched 2.1.92 + kernel). + +6. type + + quit + + to exit from the eft session. + +7. switch to the root shell's virtual console and type + + ix25test stop + + (or just ^C, if a server has been started) to shut down the test + configuration. The eftp program doesn't hangup the isdn line after + the eft connection is closed. (This is currently impossible + because the x25 socket interface does not provide for this + functionality). Therefor, it is recommended that you manually + hang up the isdn line (using "isdnctrl hangup" or shutting down + the test configuration). Your eft peer might close the isdn + connection after the eft session is finished, but you should not + rely on that. + + + +You can also try to connect with your eftp client locally to the tdu.echod +server by + + ix25test start tdu.echod 01 + +and then + + eftp 01 myname/mypass. + +However, as tdu.echod is not an eft server implementation, you will +only be able connect and disconnect. Any attempt to transfer files will +only trigger error events of the EUROFILE protocol implementation. + + +PLEASE, keep in mind that the eftp client (OVER-)writes local files. +In case of bugs, the file overwritten might be different from the file +which you specified in the target parameter of the "get" command. + + +If it doesn't work, what to do? +=============================== + +Well, this is alpha-test software and you should be able to assist +me in troubleshooting. To make this task more convenient, the ix25test +script provides some debugging support. + +If you use the script and it fails before any B-channel connection got +set up you probably did not edit the script successfully. Check it. + +If your syslog / isdnctrl messages indicate that the isdn b-channel +was successfully set up but no further data seems to be transferred, +there might be an inter-working problem of the X.25 PLP implementations. +Uncomment the line in the ix25test script where the x25trace program +is started and try again. This will leave a protocol trace in /tmp +which might be helpful in tracking down the problem. If you cannot +resolve such a problem yourself, please include that trace output in +your bug report. + +If the x.25 connections set up successfully, but eft doesn't work, the +eft error messages reported by eftp program might reveal the problem. +The eft protocol implementation is incomplete. Thus, failures are not +not unlikely to occur. + +If the standard error messages don't contain +enough information, you can make the eft programmes a lot more noisy +if you locate the line in eftp.c where the variable tdu_stderr_mask +is set. Change this to + + tdu_stderr_mask = -1 + +and recompile. A lot of debugging output (protocol and call trace) +will appear on your terminal while the eftp program is running now. + + +Problems with the kernel part might also be present. Please refer to +the appropriate PROBLEMS-* file available from the same site as this +test distribution. But I consider the kernel stuff (x25 on top of +isdn4linux extensions), which I've used since end of May 1997 now with +only marginal modifications, to be much more stable than the user +level eft implementation. However, if you faced a serious kernel bug +(usually indicated by an oops messages in the syslog output) please +report it to me. The oops message will only be meaningful to me if +the addresses are reported in symbolic form. Thus, if you faced a +kernel oops, compile the ksymoops program present in your kernel +sources "script" directory, i.e (assuming kernel source is in +/home/kernel/linux-ix25): + + cd /home/kernel/linux-ix25/scripts + g++ ksymoops.cc -o ksymoops + +The ix25test script leaves a System.map file in the /tmp directory +which contains all symbolic address mappings of the resident +kernel as well as all isdn and x25 related modules. You can use this +file with your ksymoops program. For your convenience, ix25test also +leaves a script "oops_decode" left in /tmp. Type "/tmp/oops_decode" +after the oops happened, this will fetch the oops message from your +/var/log/messages syslog protocol file and decode it to stdout. + diff --git a/eurofile/doc/design.txt b/eurofile/doc/design.txt new file mode 100644 index 00000000..95f42d8f --- /dev/null +++ b/eurofile/doc/design.txt @@ -0,0 +1,354 @@ +$Id: design.txt,v 1.1 1999/06/30 16:51:01 he Exp $ + +This document is to briefly intruduce the EUROFILE protocol stack +and to document the design of the eftp4linux EUROFILE implementation. +It is derived from an original 'white paper' that I've written to +introduce the isdn4linux EUROFILE deveoping project to other developeres. + +Enjoy, + +Henner + + +Contents: 0.0 How to Read This + + 1.1 EUROFILE Protocol Stack, General Aspects + 1.2 The ISO 8208 Protocol + 1.3 The Data Link Protocols + + 2.1 ISO 8208 / X.25 inside Linux + 2.2 Socket User Interface to Protocol Layer + 2.3 Data Links in Linux: X.25 LAP_B vs. isdn4linux x75i + + 3.1 Encapsulation + 3.2 L2 Protocol + 3.3 Providing Data-link Control Primitives to the x25 Packet Layer + + 4. EUROFILE protocol higher layers themselves and their + implementation (currently empty :-) + +0.0 How to Read This +==================== + +This document serves two purposes: + +- It give a brief introduction on how i4l was interfaced with the + X.25 network layer (sections 3.* of this article). If you are familiar + with EFT related protocols and (isdn4)linux internals you can goto 3.0 + right away and submit your comments. + +- It also givea an introduction on EFT, and ideas how it was + implemented in linux. Since it took quite some time for me + to gather all the information related to EFT, I decided to write an + introduction as the initial task of the linux EFT project. That + introduction was also a good base for documentation. + + +Sections 1.* will provide the necessary background information. + +Sections 2.* will provide background information concerning linux specific +EFT related protocol issues. If you focus on the user level part of the +EFT implementation 2.2 will be the most (or even only) important part for you. + +In sections 3.* I'd like to discuss implementation issues concerning the +kernel related part. Please comment on that (no matter, whether +you are participating in the EFT project or not). You won't need to reed +this if you are not interested in the kernel related stuff (but I've +tried to describe my ideas from the i4l end users point of view). + +Section 4 is to suggest a development strategy. + + +I've asked all EFT volunteers to subscribe to the i4l developer list. Since +I don't know whether all of them have already subscribed I also include +their addresses explicitly + + +1.1 EUROFILE Protocol Stack, General Aspects +============================================ + +From my point of view EFT is functionally similar to ftp (the purpose is to +transfer files), although the protocols used by them are totally different. +ftp runs on top of the TCP/IP protocol. EFT does not run on top of the +well supported TCP/IP protocol suite. It uses the less known (in the Unix +world) ISO-8208 network protocol instead. + +TCP/IP and ISO-8208 provide similar services to the applications, namely a +connection oriented, reliable, multiplexed, and flow-controlled exchange of +data. There are also some differences, i.e. ISO-8208 preserves messages +boundaries while tcp/ip just provides reliable byte streams. And +ISO-8208 also has some strange stuff such as qualified data (which is +used by EUROFILE). + + +1.2 The ISO 8208 Protocol +========================= + +ISO 8208 is similar to the packet layer protocol standardised by ITU-T +recommendation X.25. X.25 is widely applied in many public data networks +such as the German Datex-P network. + +I didn't get the ISO-8208 specification yet, all of my +knowledge is from secondary sources. Thus, please correct me if I'm wrong! +But as I understand others, the differences between ITU X.25 and ISO 8208 +are marginal (as far as the core functionality is concerned): + +- ITU wanted to standardise the access to public data network switches. + Therefore, ITU specified the protocol as viewded from the network + switch (the Data Circuit Equipment "DCE") +- ISO describes the protocol in terms of the user equipment (the Data Terminal + equipment "DTE") that wants to communicate via the network. + +Both standards essentially define the same protocol (but probably, the ISO +version has much more optional features which will never get implemented -:). + +ITU X.25 specifies a whole protocol stack used to connect to X.25 switches +including the X.25 Packet Layer Protocol ("PLP", the network layer/layer 3 +in terms of the OSI model), data link protocol ("LAP_B", OSI layer 2) and a +physical layer (OSI layer 1). ISO-8208 is just concerned with the network +layer. + +I guess one could also say that ITU describes the process of communicating +with an X.25 network switch (which will route the packets) while ISO +describes how to communicate with your peer entity. Thus, ITU X.25 is also +refered as X.25 DTE-DCE. ISO, in contrast, also covers direct communication +of two X.25 peer entities (without involving an X.25 switch). This mode +of operation is frequently refered as X.25 DTE-DTE. + +And this DTE-DTE mode is also used by EFT when operating over ISDN! + +You can argue that the use of a network protocol like X.25 (which supports +routing and other stuff) is unnecessary when operating over a circuit +switched ISDN (and thus a waste of resources). You might be right, +but I didn't design the EFT protocol. So, don't blame me for that. + + +1.3 The Data Link Protocols +=========================== + +ITU X.25 PLP and ISO 8208 run on top of a data link protocol. ITU X.25 +defines the LAP_B procedure itself. ISO-8208 doesn't define a data link +protocol itself. The layer-3 Protocol is just defined in terms of certain +data link service primitives which must be provided by the data link entity. + +Protocols, which provide the data link service to ISO8208 are defined in +other ISO standards. I.e. a LAP_B protocol, which provides +such data link services, is defined in ISO 7776. ISO 7776 is (almost) identical +to the X.75 data link protocol. This layer-2 protocol is well known by +isdn4linux users who frequently choose it for tty-style connections in order +to benefit from its error recovery features. + +X.75 by itself defines ITU's protocol stack to interconnect public +X.25 networks. Beside the data link protocol known by linux users, it +also defines (like X.25) a packet layer / layer 3 protocol which +is also very similar to X.25 PLP. We won't need any more information on +these (and other) X.75 procedures. + +The ISO 7776 or X.75 LAP_B protocol is again similar to the LAP_B procedure +defined in ITU X.25. + +In contrast to the packet layer / layer 3 protocols +the data link protocols are not purely symmetric: +The lap_b protocols work by exchanging "commands" and "responses". +Commands and responses are submitted on different data link addresses (the +protocols contain an address field to support this). +Usually, one peer submits commands using the data link address 1 and submits +responses using the data link address 3. The other peer sends commands on +address 3 and responses on address 1. Thus, before communication can start, +a decision has to be made on who is going to submit commands on data link 1 +and on who must submit them on address 3. + +With X.25, this decision is quite simple. The rule is that the DTE side +sends the commands on address 1 while the DCE sends the commands on address 3. + +With X.75 or ISO-8208 there is no difference between the peers. Both peer +entities are functionally equivalent. Fortunately, for isdn, there is always +one side which must set up the physical isdn B channel connection by +calling the other side before communication can start. The rule is +that the calling party uses the addresses like the DTE while the called +party uses the addresses like the DCE. + +Thus, when EFT is operated over ISDN, the latter rules will be applied. + +When you configure the X.75 l2-protocol, isdn4linux will automatically +choose the proper data link addresses according to the rule above. + + + +2.1 ISO 8208 / X.25 inside Linux +================================ + +Obviously, since EFT runs on top of ISO 8208, we definitely need an ISO +8208 protocol implementation before we can think about EFT. Fortunately, +Jonathan Naylor has add X.25 support to Linux (first kernel version +with X.25 was 2.1.16). This implementation was based on ITU-T X.25 +specificatiion. But this also works well in the ISO 8208 DTE-DTE context. + + +2.2 Socket User Interface to Protocol Layer +=========================================== + +In Unix-like operating systems, ftp clients and servers are usually +implemented as user space programs which access the TCP/IP network protocol +service of the kernel by means of the socket interface. EFT does not run on +top of tcp/ip, but on top of the ISO 8208 protocol. But an operating system +can also provide access to the ISO 8208 / X.25 protocol by means of a socket +interface. Thus, EFT servers and clients might be similarly implemented as +user space programs like ftp or ftpd. The Linux X.25 implementation provides +such a socket interface. + +To obtain information on socket programming you can start with "man socket". +There are also a lot of books which describe socket programming. + + +User space ftp eft + +Socket Interface ------------ ------------ + + tcp x25 +Kernel Space + ip lap_b + + +A lot of programmers are familiar with tcp/ip programming using the socket +interface. Since tcp/ip and x.25 provide similar services to the user, +programming an application that communicates via the X.25 protocol is +not essentially different from programming a tcp/ip application. However, +there are still some differences: + +First, the address space and protocol family will be different +(PF/AF_INET vs. PF/AF_X25). For EUROFILE which applies X.25 in DTE-DTE +mode we can use an empty X.25 address anyway. + +Second, in contrast to tcp/ip, X.25 preserves packet +boundaries. Thus, a SOCK_SEQPACKET type socket is used for X.25 while +tcp/ip uses SOCK_STREAM type sockets. If you write N bytes to a SOCK_SEQPACKET +socket using the Unix write() system call, then a read() +from the corresponding peer socket will return the same N bytes of data +as written. With stream sockets, this is generally not the case (the boundaries +of the written and read chunks won't necessarily match). + +EFT also needs so called X25 qualified data to be transmitted. +The Linux X.25 protocol stack supports a special socket option that +makes the X.25 Q-Bit (which is used by the X.25 PLP to mark qualified +data packets) transparent to the uses. + + +2.3 Data Links in Linux: X.25 LAP_B vs. isdn4linux x75i +========================================================== + +X25 needs a data link protocol implementation. The Linux X25 PLP is designed +to interface directly to a Linux network interface. It requires the network +interface to implement the X.25 data link protocol (this design decision has +been made in order to make use of intelligent X25 cards which implement the +LAP_B protocol in firmware). Jonathan Naylor has also written a lapb_module +which can be used by all x25 network interface driver developers who don't +want to implement the lap_b protocol on their own (see +Documentation/networking/lapb-module.txt). + +i4l also supports a lap_b protocol (l2_prot x75i). The protocol is also +implemented below the network interface. Thus, the situation was almost as +required by the X25 PLP implementation. + +However, there was one difference: + +In the beginning of the isdn4linux EUROFILE project, i4l's x.75 only +allowed the upper protocol layers to send and receive data. +A user might send data to the i4l x.75 data link entity at any time. +When the data link is in the "connected" state, than i4l's x.75 protocol +implementation will just send the data to the peer. If the data link is not +in the "connected" state then i4l will automatically established the data link +first. After it has been established, the data will be send. No special user +intervention was (and still is) needed for establishing the data link, +i4l takes care on this. + +The X25 PLP protocol, in contrast, wants to control the establishment +and release of the data link by itself. Therefore, an X.25 lap_b +implementation must provide all the lap_b service primitives +(DL_DATA request/indication, DL_ESTABLISH request/indication/confirm, +DL_RELEASE request/indication/confirm) to the upper protocol layers (and in +turn doesn't need to bother with automatic establishment procedures). Each +message exchanged between the X.25 LAP_B network interface and the X25 PLP +gets prepended a special byte. This byte is used to distinguish between the +different DL service primitives. It is not part of the protocol data units to +be sent to or received from the peer. (see +Documentation/networking/x25-iface.txt for details) + +Remark: The lapb module only provides the protocol implementation. The +interpretation of the leading control byte as defined in x25-iface.txt +must be performed by the x25-network-interface-device driver which uses +the lapb module. + + +3. Providing the X.25 lap_b Interface in i4l +============================================= + +3.1 Encapsulation +================= + +Some method of providing the LAP_B data link service primitives to +the Linux X.25 layer needed to be implemented. + +This was done by means of a new encapsulation type for isdn4linux +network interfaces. This encapsulation is turned on in the same manner +as all other encapsulation, namely by the isdnctrl command, e.g. + +"isdnctrl encap isdn0 x25iface" + +configures an isdn4linux network interface for use by the X25 PLP. + +This is only to indicate that the messages sent through the network interface +are formatted according to the Linux' x25-lapb interface specification. +(it might also be used by the device driver to take special actions which are +specific for communicating with the x25 PLP layer). But the encapsulation +doesn't specify how lower parts of i4l system will provide the data link +service. (the encap doesn't specify the data link protocol which provides the +data link service, but the protocol used between the network device and the +network protocol layers). + + +3.2 L2 Protocol +=============== + +The data link protocol used to communicate between two peers is specified +as usual by the l2_prot parameter. For EFT, + +"isdnctrl l2_prot isdn0 x75i" + +is used and no new protocol implementation was necessary. + +However, it might be a good opportunity to reserve two new +l2_prot parameters, namly x25_dte and x25_dce. These specify almost the same +as x75i, the only difference is that the data link addresses used for commands +and responses will be fixed (in X.75 they depend on who initiates the +corresponding call). + +The x25_dte or dce l2-protocols are not needed for EFT, but +they might enable other x25 users to access public x25 data networks by +means of i4l b_channels (dialup as well as leased lines). Maybe some +x25 folks will be quite happy about this. + + +3.3 Providing Data Link Control Primitives to the x25 Packet Layer +================================================================== + +One design question was how to provide the LAP_B protocol service by i4l. +(interpreting and setting the first byte and mapping them on the DL primitives +according to Documentation/networking/x25-iface.txt). + +The final implementation used the existing x.75 L2 protocol +present in the HL level drivers but implemented the processing of the +first-byte (as specified in Documentation/networking/x25-iface.txt) +entirely in the isdn4linux link level module. This +was possible without any extension to the isdn4linux LL-HL driver interface. +Thus, no hardware level driver needed to be adopted and every hardware +level driver that supports l2prot x75i can be used for EUROFILE. +(This already turned out to be a FAQ: does Linux EUROFILE work with my +xy-isdn-card? Answer: Yes, if the card supports l2prot x75i. In +patricular all cards supported by HiSax work) + + +4. EUROFILE protocol higher layers themselves and their implementation +====================================================================== + +TO BE ADDED diff --git a/eurofile/doc/eft_wuauth.5 b/eurofile/doc/eft_wuauth.5 new file mode 100644 index 00000000..762a08be --- /dev/null +++ b/eurofile/doc/eft_wuauth.5 @@ -0,0 +1,182 @@ +.\" $Id: eft_wuauth.5,v 1.1 1999/06/30 16:51:02 he Exp $ +.\" Copyright (c) 1985, 1988 The Regents of the University of California. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms are permitted provided +.\" that: (1) source distributions retain this entire copyright notice and +.\" comment, and (2) distributions including binaries display the following +.\" acknowledgement: ``This product includes software developed by the +.\" University of California, Berkeley and its contributors'' in the +.\" documentation or other materials provided with the distribution and in +.\" all advertising materials mentioning features or use of this software. +.\" Neither the name of the University nor the names of its contributors may +.\" be used to endorse or promote products derived from this software without +.\" specific prior written permission. +.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED +.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. +.\" +.\" ORIGINAL: ftpd.8 6.8 (Berkeley) 6/24/90 +.\" +.\" @(#)$Original-Id: ftpd.8,v 1.5 1997/01/14 22:45:27 sob Exp sob $ +.\" +.TH EFT_WUAUTH 5 "Jan 10, 1997" +.UC 5 +.SH NAME +eft_wuauth \- authentication for eftp4linux Eurofile server based on wuftpd. +.SH DESCRIPTION +If the eftp4linux Eurofile server +.I eftd +is compiled with the CONFIG_EFTD_WUAUTH configuration option, +it uses user authentication code derived from +.I wuftpd, +the Washington University ftp daemon. +.PP +In that case +.I eftd +authenticates users according to four rules. +.IP 1) +The user name must be in the password data base, +.IR /etc/passwd , +or whatever is appropriate for the operating system, +and the password must not be null. In this case a password +must be provided by the client before any file operations +may be performed. +.IP 2) +The user name must not appear in the file +.IR /etc/isdn/eftusers . +.IP 3) +The user must have a standard shell returned by +.IR getusershell (3). +If login failed for certain users, maybe that's because their login +shell is not listed in /etc/shells. +.IP 4) +If the user name is ``anonymous'' or ``ftp'', an +anonymous ftp account must be present in the password +file (user ``ftp''). In this case the user is allowed +to log in by specifying any password (by convention this +is given as the client host's name). +.PP +In the last case, +.I eftd +takes special measures to restrict the client's access privileges. +The server performs a +.IR chroot (2) +command to the home directory of the ``ftp'' user. +In order that system security is not breached, it is recommended +that the ``ftp'' subtree be constructed with care; the following +rules are recommended. +.IP ~ftp) +Make the home directory owned by super-user and unwritable by anyone. +.IP ~ftp/bin) +Make this directory owned by the super-user and unwritable by +anyone. This contains auxilary programs that might be forked by +.IR eftd(8) +or +.IR ftpd(8). +These programs should have mode 111. +.IR eftd(8) +currently does not need any auxilary programs. Thus, you only need to +put files here if you also want to provide anonymous ftp service. +.IP ~ftp/etc) +Make this directory owned by the super-user and unwritable by +anyone. The files +.IR passwd (5) +and +.IR group (5) +must be present for eftd +to be able to produce owner names rather than numbers in file headers +and extended format directory (T-DIR primitive) listings. Depending +on the operating system, there may be other required files. Check your +manual page for the +.IR getpwent (3) +library routine. +The password field in +.I passwd +is not used, and should not contain real encrypted passwords. +These files should be mode 444 and owned by the super-user. +Don't use the system's /etc/passwd file as the password file or +the system's /etc/group file as the group file in the ~ftp/etc directory. +.IP ~ftp/pub) +Create a subdirectory in ~ftp/pub +with the appropriate mode (777 or 733) if you want to allow normal +users to upload files. + +.PP +The Eurofile file server also allows for finer grained access control +by means of the files /etc/isdn/eftaccess and /etc/isdn/efthosts. + +.SH "COPYING" +The main part of eftp4linux is licensed under the LGPL. However, +eft servers using the wuauth authentication libray also contain code +copyrighted by the University of California, Berkeley, +by the Washington University in Saint Louis, and their contributors. +That code is subject to a BSD style licences with advertisment clause: + +Copyright (c) 1990 The Regents of the University of California. +All rights reserved. + +This code is derived from software contributed to Berkeley by +Chris Torek. +Redistribution and use in source and binary forms are permitted +provided that: (1) source distributions retain this entire +copyright notice and comment, and (2) distributions including binaries +display the following acknowledgement: ``This product includes software +developed by the University of California, Berkeley and its contributors'' +in the documentation or other materials provided with the distribution +and in all advertising materials mentioning features or use of this +software. Neither the name of the University nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. +THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright (c) 1993, 1994 Washington University in Saint Louis +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: 1. Redistributions of source code must retain the above +copyright notice, this list of conditions and the following +disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. All advertising materials mentioning features or use of this +software must display the following acknowledgement: This product +includes software developed by the Washington University in Saint +Louis and its contributors. +4. Neither the name of the University nor the names of its +contributors may be used to endorse or promote products derived from +this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY WASHINGTON UNIVERSITY AND CONTRIBUTORS +``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL WASHINGTON +UNIVERSITY OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER +CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +POSSIBILITY OF SUCH DAMAGE. + + + +.SH "SEE ALSO" +.BR eftd(1) , +.BR shells(5) , +.BR getusershell(3) , +.BR eftaccess(5) , +.BR efthosts(5) , +.BR eft_xferlog(5) , +.BR umask(2) +.SH BUGS +The anonymous account is inherently dangerous and should be +avoided when possible. + +The eftaccess amd efthosts files are currently not yet working as documented. diff --git a/eurofile/doc/eft_xferlog.5 b/eurofile/doc/eft_xferlog.5 new file mode 100644 index 00000000..f11c1a7d --- /dev/null +++ b/eurofile/doc/eft_xferlog.5 @@ -0,0 +1,168 @@ +.\" $Id: eft_xferlog.5,v 1.1 1999/06/30 16:51:03 he Exp $ +.TH EFT_XFERLOG 5 +.SH NAME +eft_xferlog \- EFT server logfile +.SH DESCRIPTION +.LP +The +.B eft_xferlog +file contains logging information from the eftp4linux eurofile server daemon, +.BR eftd (8). +This file usually is found in /var/adm, but can be located anywhere by using a +option to +.BR eftd (8). +.P +eftd uses the same format as wu-ftpd for its log files. Thus, you +might be able to use or adapt tools that have been written to analyse +wu-ftpd xferlog files. However, for some fields of the log file +different semantics apply. This is because they are now +related to the isdn domain rather than the internet. +.P +Each server entry is composed of a single line of the following form, +with all fields being separated by spaces. +.IP +.I +current-time\ \ transfer-time\ \ remote-host\ \ file-size\ \ filename\ \ transfer-type\ \ special-action-flag\ \ direction\ \ access-mode\ \ username\ \ service-name\ \ authentication-method\ \ authenticated-user-id +.LP +.TP 20 +.I current-time +is the current local time in the form "DDD MMM dd hh:mm:ss YYYY". Where DDD +is the day of the week, MMM is the month, dd is the day of the month, +hh is the hour, mm is the minutes, ss is the seconds, and YYYY is the year. +.TP +.I transfer-time +is the total time in seconds for the transfer. +.TP +.I remote-host +is the remote host's isdn number. +.TP +.I file-size +is the size of the transferred file in bytes. +.TP +.I filename +is the name of the transferred file. +.TP +.I transfer-type +is a single character indicating the type of transfer. Can be one of: +.RS +.RS +.PD 0 +.TP 10 +.B a +for an ascii transfer +.TP +.B b +for a binary transfer +.PD +.RE +.RE +As eftp4linux only supports binary transfers, this will +allways be 'b'. +.TP +.I special-action-flag +is one or more single character flags indicating any special action taken. +Can be one or more of: +.RS +.RS +.PD 0 +.TP 10 +.B C +file was compressed +.TP +.B U +file was uncompressed +.TP +.B T +file was tar'ed +.TP +.B _ +no action was taken +.PD +.RE +.RE +As on-the-fly-compression is not supported by eftp4linux, +this will always be '_'. +.TP +.I direction +is the direction of the transfer. Can be one of: +.RS +.RS +.PD 0 +.TP 10 +.B o +outgoing +.TP +.B i +incoming +.PD +.RE +.RE +.TP +.I access-mode +is the method by which the user is logged in. Can be one of: +.RS +.RS +.PD 0 +.TP 10 +.B a +(anonymous) is for an anonymous guest user. +.TP +.B g +(guest) is for an passworded guest user (see the +.BR guestgroup +command in +.BR eftaccess(5) +). +.TP +.B r +(real) is for a local authenticated user. +.PD +.RE +.RE +.TP +.I username +is the local username, or if guest, the ID string given. +.TP +.I service-name +is the name of the service being invoked, which is EFT. +.TP +.I authentication-method +is the method of authentication used. Can be one of: +.RS +.RS +.PD 0 +.TP 10 +.B 0 +none +.TP +.B 1 +RFC931 Authentication +.PD +.RE +.RE +As RFC931 authentication is not used by eftp4linux, this will always +be 0. +.TP +.I authenticated-user-id +is the user id returned by the authentication method. +A * is used if an authenticated user id is not available. With +eftp4linux, this will be the same as the user name. +.SH CREDITS +.LP +This man page has been derived from the wuftpd +.BR xferlog(5) +man page. Please refer to the +.BR eft_wuauth(5) +man page for further details. +.SH FILES +.PD 0 +.TP 20 +.B /var/log/xferlog +.SH "SEE ALSO" +.BR ftpd(8), +.BR ftpaccess(5), +.BR xferlog(5), +.BR eftd(8), +.BR eftaccess(5), +.BR eft_wuauth(5) + diff --git a/eurofile/doc/eftaccess.5 b/eurofile/doc/eftaccess.5 new file mode 100644 index 00000000..1cde4503 --- /dev/null +++ b/eurofile/doc/eftaccess.5 @@ -0,0 +1,334 @@ +.\" $Id: eftaccess.5,v 1.1 1999/06/30 16:51:04 he Exp $ +.\" SCCSID: @(#)$Original-Id: ftpaccess.5,v 1.7 1997/01/10 06:27:02 sob Exp $ +.\" +.\" +.TH eftaccess 5 +.SH Name +eftaccess \- eftd configuration file +.SH Description +The eftaccess file is used to configure the operation of +.BR eftd(1) . +.SH Access Capabilities +.TP 0.5i +.B autogroup [ ...] +If an ANONYMOUS user is a member of any of , the ftp +server will perform a setegid() to . This allows +access to group-and-owner-read-only files and directories to +a particular class of anonymous users. is a valid +group from /etc/group (or wherever mechanism your +.IR getgrent(2) +library routine uses). +.TP 0.5i +.B class [ ...] +Define of users, with source addresses of the form +. Multiple members of may be defined. There +may be multiple "class" commands listing additional members of +the class. If multiple "class" commands can apply to the +current session, the first one listed in the access file is +used. Failing to define a valid class for a host will cause +access to be denied. is a comma-separated list of +any of the keywords "anonymous", "guest" and "real". If the +"real" keyword is included, the class can match users using FTP +to access real accounts, and if the "anonymous" keyword is +included the class can match users using anonymous FTP. The +"guest" keyword matches guest access accounts (see "guestgroup" +for more information) + + may be a globbed isdn number. +.TP 0.5i +.B deny +Always deny access to host(s) matching . +is displayed. +.TP 0.5i +.B guestgroup [ ...] +If a REAL user is a member of any of , the session +is set up exactly as with anonymous FTP. In other words, a +chroot() is done, and the user is no longer permitted to issue +the USER and PASS commands. is a valid group +from /etc/group (or whatever mechanism your +.IR getgrent(3) +library routine uses). + +The user's home directory must be properly set up, exactly as +anonymous FTP would be. The home directory field of the +passwd entry is divided into two directories. The first +field is the root directory which will be the argument +to the +.IR chroot(2) +call. The second half is the user's +home directory relative to the root directory. The +two halves are separated by a "/./". + +Example: + +in /etc/passwd, the real entry: + +guest1::100:92:Guest Account:/ftp/./incoming:/etc/ftponly + +When guest1 successfully logs in, the ftp server will +chroot("/ftp") and then chdir("/incoming"). The +guest user will only be able to access the directory structure +under /ftp (which will look and act as / to guest1), just as an +anonymous FTP user would. +.TP 0.5i +.B limit +(currently not applicable to eftd) +.P +Limit to users at times , displaying + if user is denied access. Limit check is +performed at login time only. If multiple "limit" commands can +apply to the current session, the first applicable one is +used. Failing to define a valid limit, or a limit of -1, is +equivalent to unlimited. is in same format as the times +in the UUCP L.sys file. +.TP 0.5i +.B noretrieve .... +(currently not applicable to eftd) +.P +Always deny retrieve-ability of these files. If the files are an +absolute path specification (i.e. begins with '/' character) then +only those files are marked un-gettable, otherwise all files with +matching the filename are refused transfer. Example: + + noretrieve /etc/passwd core + +specifies no one will be able to get the file /etc/passwd whereas +they will be allowed to transfer a file `passwd' if it is not in +/etc. On the other hand no one will be able to get files named +`core' wherever it is. + +No globbing is done. +.TP 0.5i +.B loginfails +(currently not applicable to eftd) +.P +After login failures, log a "repeated login failures" +message and terminate the FTP connection. Default value is 5. +.TP 0.5i +.SH Informational Capabilities +.TP 0.5i +.B banner +Works similarly to the message command, except that the banner +is displayed before the user enters the username/password. The + is relative to the real system root, not the base of the +anonymous FTP directory. +.TP 0.5i +.B email +Defines the email address of the ftp archive maintainer. This string +will be printed every time the %E magic cookie is used. +.TP 0.5i +.B message { { ...}} +(currently not applicable to eftd) +.P +Define a file with such that ftpd will display the +contents of the file to the user login time or upon using the +change working directory command. The parameter may be +"LOGIN" or "CWD=". If is "CWD=", +specifies the new default directory which will trigger the +notification. + +The optional specification allows the message to be +displayed only to members of a particular class. More than one +class may be specified. + +There can be "magic cookies" in the readme file which cause the +ftp server to replace the cookie with a specified text string: + + %T local time (form Thu Nov 15 17:12:42 1990) + %F free space in partition of CWD (kbytes) + [not supported on all systems] + %C current working directory + %E the maintainer's email address as defined in ftpaccess + %R remote host name + %L local host name + %u username as determined via RFC931 authentication + %U username given at login time + %M maximum allowed number of users in this class + %N current number of users in this class + +The message will only be displayed once to avoid annoying the +user. Remember that when MESSAGEs are triggered by an +anonymous FTP user, the must be relative to the base of +the anonymous FTP directory tree. +.TP 0.5i +.B readme { {}} +Define a file with such that ftpd will notify user at +login time or upon using the change working directory command +that the file exists and was modified on such-and-such date. +The parameter may be "LOGIN" or "CWD=". If +is "CWD=", specifies the new default directory which +will trigger the notification. The message will only be +displayed once, to avoid bothering users. Remember that when +README messages are triggered by an anonymous FTP user, the + must be relative to the base of the anonymous FTP +directory tree. + +The optional specification allows the message to be +displayed only to members of a particular class. More than one +class may be specified. +.SH Logging Capabilities +.TP 0.5i +.B log commands +Enables logging of individual commands by users. is +a comma-separated list of any of the keywords "anonymous", +"guest" and "real". If the "real" keyword is included, logging +will be done for users using FTP to access real accounts, and +if the "anonymous" keyword is included logging will done for +users using anonymous FTP. The "guest" keyword matches guest +access accounts (see "guestgroup" for more information). +.TP 0.5i +.B log transfers +Enables logging of file transfers for either real or anonymous +FTP users. Logging of transfers TO the server (incoming) can +be enabled separately from transfers FROM the server +(outbound). is a comma-separated list of any of the +keywords "anonymous", "guest" and "real". If the "real" +keyword is included, logging will be done for users using FTP +to access real accounts, and if the "anonymous" keyword is +included logging will done for users using anonymous FTP. The +"guest" keyword matches guest access accounts (see "guestgroup" +for more information). is a comma-separated list +of any of the two keywords "inbound" and "outbound", and will +respectively cause transfers to be logged for files sent to the +server and sent from the server. +.SH Miscellaneous Capabilities +.TP 0.5i +.B alias +Defines an alias, , for a directory. Can be +used to add the concept of logical directories. + +For example: + alias rfc: /pub/doc/rfc + +would allow the user to access /pub/doc/rfc from any +directory by the command "cd rfc:". Aliases only +apply to the cd command. +.TP 0.5i +.B cdpath +Defines an entry in the cdpath. This defines a search path that is used +when changing directories. + +For example: + + cdpath /pub/packages + cdpath /.aliases + +would allow the user to cd into any directory directly under +/pub/packages or /.aliases directories. The search path is defined by +the order the lines appear in the ftpaccess file. + +If the user were to give the command: + + cd foo + +The directory will be searched for in the following order: + + ./foo + an alias called "foo" + /pub/packages/foo + /.aliases/foo + +The cd path is only available with the cd command. If you have a large +number of aliases you might want to set up an aliases directory with +links to all of the areas you wish to make available to users. +.TP 0.5i + +.SH Permission Capabilities +(currently not applicable to eftd) +.P +.TP 0.5i +.B chmod +.TP 0.5i +.B delete +.TP 0.5i +.B overwrite +.TP 0.5i +.B rename +.TP 0.5i +.B umask +Allows or disallows the ability to perform +the specified function. By default, all users +are allowed. + + is a comma-separated list of any of the +keywords "anonymous", "guest" and "real". +.TP 0.5i +.B passwd-check () +Define the level and enforcement of password checking +done by the server for anonymous ftp. + + none no password checking performed. + trivial password must contain an '@'. + rfc822 password must be an rfc822 compliant address. + + warn warn the user, but allow them to log in. + enforce warn the user, and then log them out. +.TP 0.5i +.B path-filter { ...} +(currently not applicable to eftd) +.P +For users in , path-filter defines regular expressions +that control what a filename can or can not be. There may be +multiple disallowed regexps. If a filename is invalid due to +failure to match the regexp criteria, will be displayed to +the user. For example: + + path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9\._]*$ ^\. ^- + +specifies that all upload filenames for anonymous users must be +made of only the characters A-Z, a-z, 0-9, and "._-" and may not +begin with a "." or a "-". If the filename is invalid, /etc/pathmsg +will be displayed to the user. +.TP 0.5i +.B upload ["dirs"|"nodirs"] +Define a directory with that permits or +denies uploads. + +If it does permit uploads, all files will be owned +by and and will have the permissions +set according to . + +Directories are matched on a best-match basis. + +For example: + upload /var/ftp * no + upload /var/ftp /incoming yes ftp daemon 0666 + upload /var/ftp /incoming/gifs yes jlc guest 0600 nodirs + +This would only allow uploads into /incoming and +/incoming/gifs. Files that were uploaded to +/incoming would be owned by ftp/daemon and would +have permissions of 0666. File uploaded to +/incoming/gifs would be owned by jlc/guest and +have permissions of 0600. Note that the here must +match the home directory specified in the password database for the +"ftp" user. + +The optional "dirs" and "nodirs" keywords can be +specified to allow or disallow the creation of +new subdirectories using the mkdir command. + +The upload keyword only applies to users who +have a home directory (the argument to the chroot() ) +of . +.SH Files +FTPLIB/ftpaccess +.SH See Also +.BR ftpd(8), +.BR umask(2) , +.BR ftplog(5) , +.BR ftpconversions(5) , +.BR ftpshut(8) +.SH BUGS +The eftaccess features are mainly untested. Most of this man page is +not finished. In particular, don't expect any feature to work that is +used for anything else but authenticating a user logging in. + + + + + + + + + diff --git a/eurofile/doc/eftd b/eurofile/doc/eftd new file mode 100644 index 00000000..5fcb59ed --- /dev/null +++ b/eurofile/doc/eftd @@ -0,0 +1,293 @@ +$Id: eftd,v 1.1 1999/06/30 16:51:05 he Exp $ + +Sorry, rather incomplete and not in man page format. + +But feel free to submit patches :-) + + +eftd: eftp4linux EUROFILE transfer server. + +eftd allows clients to connect to your machine via the ISDN and to +transfer files by means of the EUROFILE transfer protocol. That +protocol is specified by ETSI norms ETS 300-075 and ETS 300-383. + +Unless the -s option is given, the server loops forever waiting for +incoming connections and forks a child process for each connection +received. + + +Synopsis: + +As this is alpha test software, options might change with each release! + + eftd [-a [ACCESS_FILE]] [-IlsV?] [-d LEVEL] [-D MASK] + [-b LOGFILE] [-l LEVEL] [-L MASK] + [-U FALLBACK_USER_ID] [-x ADDR] + +OPTIONS + + -a Expects a string argument interpreted as a file name. + If eftd is compiled with the CONFIG_EFTD_WUAUTH + option, eftd reads ACCESS_FILE and uses the contents + for user authentication similarly to wu-ftpd's + ftpaccess file. See eftaccess(5) for further details. + + -b Expects a string argument interpreted as a file name. + Communication events selected by the -l or -L option + are logged (appended) to the file specified by the + option's argument. (This is the 'LogBook' file in + terms of ETS 300 383, thus the 'b'). If this option is + omitted, a system dependent default (i.e. + /var/log/eftd.log) is used. Opening of the LogBook + file can be supressed simply by not suppling any -l or + -L option. + + -d Expects an integer argument which is interpreted as a + log level. Protocol or internal events up to the level + are logged to stderr. + + For levels 0 - 3, see the -l option. + + Higher values include more events in the log, + such as low level protocol and call traces and + temporarily inserted debugging output statements. + + Use of -d as well as level > 3 is primarily intended + for debugging purpose. This also implies that the + output caused by log levels > 3 is not documented and + likely to change between releases. + + -D The bitmask argument allows for low level grained + control of stderr output. It overrides previous + -I and augments -d options. For maximum amount of + debugging output use "-D -1". As this is really + intended to be used for low level debugging, examine + the eftp4linux sources (start by reading the source + file src/lib/tdu_user.h) if you really want to use + this option on your own. + + -I Logs the contents of /dev/isdnctrl to stderr. For this + to work, other processes reading /dev/isdnctrl (i.e. + isdnlog) should be stopped before). This option is + intended for debugging purpose only. + + -l The integer argument specifies the log level for + selecting the events written to the LogBook file + (as specified by the -b option). Levels are + + 0 No events at all. + 1 Important events related to session start + and end (login and logout) + 2 Important events during each session. + Also adds some events related session + start/stop of minor priority. + 3 Other minor priority events. + >3 Low level events. As these are primarily + useful for debugging purpose, it's probably + better (but not strictly necessary) to log + them by means of the -d option. See the latter + for more info. + + CAUTION: this log feature is currently new, extremly + unfinished, incomplete and subject to improvements + (volunteers welcome) and not my highest priority item. + Thus, don't expect the current format of the messages + to be fixed forever. + + -L Conceptually similar to -D (see the latter). Allows + fine grained control for selecting the events logged + to the LogBook (-b) file. + + -x The string type argument should consist of up to 15 + digits which specify the X.25 [X.121/X.301] address + the servers listens on for incoming connections. As + EUROFILE is usually used with ISO-8208 X.25 DTE-DTE + mode, you should use the empty string as argument + here, which is the default. Thus, it is extremely + unlikely that you want to use this option at all. + + This option can be given two times, allowing the + server to listen on two different x25 addresses + simultaneously. + + -s Single process mode. If this option is given, the + server just serves the first incoming connection and + exits when the session is finished. It does not fork a + child process for serving that connection. + + This is mainly useful for running eftd under the + control of a debugger (such as gdb). If you want to + debug eftd like this, also make sure that the '-m' + option is not set. (As the -m option forks an additional + supervisor process, -s alone will not result in a + debuggable single process eftd). Further, as the + single process will not run under root permissions any + longer after an EUROFile connection has been accepted, + eftd can not clear isdn connections on its own, you + may need to do so yourself. + + -m Multiple connection mode. If this option is given, the + server immidiately continues to accept new connections + without waiting for the just accepted session to finish. + The number of simultaneous served connections is not + internally limited by the server. However, upper + limits might be imposed by the mumber of physically + available isdn B-channels, the number of running + incoming isdn network interfaces configured with + "encap x25iface", or by the authentification procedure + (i.e. group limits configured in /etc/isdn/eftaccess). + + When multi mode is activated, the server forks an + extra privileged supervisor process for each accepted + connections which takes care of clearing the isdn + connection after the session is finished. Thus, if N + EURFILE sessions are active, there will be 2N+1 eftd + processes. + + -U USER When this option is specified, a login attempt + with a user name not in the passwd database will + be using USER as the login name (with empty password). + + You might use '-U ftp' if you have configured + anonymous access and want that unknown user ids + should be handled as an anonymous eft access. + Unknown user ids frequently occur as many clients + insert some dummy user name in the t_associate request + if no user name was configured. + + -V Prints version. + + -? prints usage message. + +FEATURES + +The server supports most of the EUROFILE primitives, +including navigation and extended directory format. +However, T-RENAME, T-DELETE, and LIST are not supported yet. + +If eftd is compiled with the CONFIG_EFTD_WUAUTH option, user access +is granted using an authentication procedure derived from wu-ftpd, +the Washington University ftp server. Refer to the eft_wuauth man +page for further details. + +Transfers can be logged to /var/log/eft_xferlog. The format of this file +is compatible with the wu-ftpd xferlog format. Refer to the +eft_xferlog man page for details. Also see event logging below. + + +eftd can also be invoked (and then stopped) by means of the eftd.sh +shell script: + + eftd.sh start|stop + +This script reads configuration parameters (usually from +/etc/isdn/eft.conf). You might want to edit this file before +starting it. + +Besides starting eftd, the script also takes care of setting up +the necessary isdn network interfaces. The script can be used by +sysvinit to automatically start eft service as part of the system boot +precedure. (But make sure it is called after isdn and x25 modules are +loaded). + + +TRANSFER NAMES + +The EUROFILE protocol identifies files to be transferred by means of a +so called `transfer name'. According to ETS 300-383/ETS 300-075, +a transfer name may constist up to 8 keywords separated by the '/' +character. Each keyword may constist of up to 12 printable +(between 0x21 and 0x7e) ascii characters except '(', ')', '*', +'+', and '/'. The total length of the transfer name must not exceed 70 +bytes. + +The transfer names generated by eftd (and which will be displayed in +response to a T-Directory request) will always conform to this. + +eftd will also accept transfer names within incoming request +(T-Load and T-Save request) that do not conform to the standards. +If a transfer name in an incoming request is valid, it is processed +by a mapping procedure which resolves to a file name. Transfer names +not conforming to the standard are not subject to mapping. They are +treated literally as POSIX filenames. + + +TRANSFER NAME MAPPING + +eftd maps transfer names to file names by means of two different +methods. If the current working directory is writable by the user, +a database is used that maps between transfer names and file names. + +The database is currently implemented by means of symlinks which are +created in the working directory. Symlinks matching .++eft_fn.TRANSFER_NAME +contain the file name corresponding to TRANSFER_NAME. Symlinks +matching .++eft_tn.FILE_NAME contain the transfer name name +corresponding to FILE_NAME. You can clean tha database by just +removing all those symlinks (rm .++eft_[ft]n.*). + +If the directory is not writable by the user, an algorithm based ob +the file/transfer name and the file's inode number is used to map between +transfer names and file names. + + + +EVENT LOGGING + +eftd provides for two event logging channels. The first is always +stderr, the other is the so called LogBook file (an ETS 300 383 term) +(which might be altered by means of the -b option) + +The amount of events logged can be controlled by a log level, which +may be supplied by means of the -d (for stderr channel) or the -l (for +LogBook file channel). An even finer grained (but even less portable) +control is possible by means of bitmask arguments supplied with the +-D or -L option. + +For debugging purpose, it is somtimes helpful to write the standard +error messages syncronized with the logged events into the same stream. +Thus, for generating debugging logs, it is preferable to use the +stderr channel. For debugging certain very low (i.e. Linux kernel) +level protocol problems, it is even desirable to write the isdn +events (as read from /dev/isdnctrl) to the same stream. eftd provides +for a -I option to achieve this goal as close as possible (however, +synchronity cannot be granted here). + +Wenn large log levels are used, huge amounts of stderr output will be +generated. Thus you might consider to redirect stderr to a disk file +in such a case. + +Writing to a log file might block the eftd process, which might +result in timing problems if the process is blocked for a very long +(several seconds) time. Thus, it is not advisable to log events to +files (i.e. located on unreliable NFS servers) which are likly to +cause such blocking. + + +INTERWORKING PROBLEMS + +The majority of DOS/Windows based clients implicitly assume that +file transfer names fulfil DOS file name conventions and don't +distinguish between upper and lower case names. This is in violation +to the ETSI norms and might cause inter-working problems. +The server provides for a compatibility mode to inter-operate +with such clients. In order to activate that compatibility mode, +prepend a '+' character to the login name when connecting to the +server. See the doc/INTERWOKING file for details. + +If you intend to offer files for public download via eft, +it is recommended to use file names that match DOS conventions +only. + + +RESTRICTIONS (also called BUGS :-) + +Renaming and deleting (T-RENAME, T-DELETE) of files is not supported yet. +The S-LIST primitive (recursivly listing all directories) is not +supported. + +Compression is not supported. This is not a serious limitation +nowadays because on-disk compression formats like [g]zip are widley +available, compress better, and also save disk storage. + + + diff --git a/eurofile/doc/efthosts.5 b/eurofile/doc/efthosts.5 new file mode 100644 index 00000000..205b5cec --- /dev/null +++ b/eurofile/doc/efthosts.5 @@ -0,0 +1,25 @@ +.\" $Id: efthosts.5,v 1.1 1999/06/30 16:51:06 he Exp $ +.\" SCCSID: @(#)$Original-Id: ftphosts.5,v 1.2 1997/01/10 06:27:02 sob Exp $ +.\" based on ftphosts.5 1.2 1/26/93 +.\" +.TH ftphosts 5 +.SH Name +ftphosts \- ftpd individual user host access file +.SH Description +The ftphosts file is used to allow or deny access to certain +accounts from various hosts. +.SH Access Capabilities +.TP 0.5i +.B allow [ ...] +Only allow host(s) matching to log in as . +.TP 0.5i +.B deny [ ...] +Always deny host(s) matching to log in as . +.SH Files +FTPLIB/ftphosts +.SH See Also +.BR ftpd(8) , +.BR ftpaccess(5) , +.BR ftplog(5) , +.BR ftpconversions(5) , +.BR ftpshut(8) diff --git a/eurofile/doc/eftp b/eurofile/doc/eftp new file mode 100644 index 00000000..d8146112 --- /dev/null +++ b/eurofile/doc/eftp @@ -0,0 +1,261 @@ +$Id: eftp,v 1.1 1999/06/30 16:51:06 he Exp $ + +Sorry, rather incomplete and not in man page format. + +But feel free to submit patches :-) + + +eftp is a simple EUROFILE transfer client with a command line user +interface roughly resembling the ftp client. + +Synopsis: + +eftp should currently not be invoked directly be the user but by means of +the eftp.sh shell script: + + eftp.sh ISDN_NUMBER [ID] + +where ISDN_NUMBER is the isdn number of the peer server to connect to. +ID is usually entered as USER or USER/PASSWD, consisting of the +userid and the password on the remote EUROFILE server. + +Future versions of eftp will support the following command line +options: + + -i ISDN_NO + specify the isdn no of the remote EUROFILE + server to connect to. The server will try to + set up an isdn connection to this number and + an X.25 DTE-DTE connection on top of this. + + -x X.25_ADDRESS + directly specify the X.25 address used for + setting up the X.25 connection. For eftp to + work, an X.25 route for that address must + already be present. The X.25 route must point + to an isdn4linux network interface that is + configured for outgoing connections to a + destination EUROFILE server. The encapsulation + of the interface must be "x25iface". + + -u USER[/PASSWORD] + The user identity used to login to the + remote EUROFILE server. The password can + be appended to the user id seperated by a + '/' character. If no '/' is present in the + paramater of the -u option, eftp will prompt + for a password. + +CAUTION: + + Entering the password on the command line allows other users + to spoof the password, i.e. by means of the ps command. The + password might also leave other traces, i.e. in your shell's + history file. Thus, DON'T include the passwd in the -u argument + on machines where this is a concern (i.e. when untrusted users + have shell accounts on the machine). + + If the -u option is missing, the client will + try to login without a user id (some servers + will treat this as anonymous access). + + -p suppress prompting for a password even if the + argument to the -u option does not contain a + password. This is useful for accounts on + EUROFILE servers without password protection. + + -h print a help message to stdout. + + + +In order to set up isdn4linux network interfaces, the eftp.sh script +needs to be called from the root user. Before the eftp program itself +is executed, the userid is switched (configurable in the +/etc/isdn/eft.conf file) and the working directory is changed to /tmp. +(This is an interim measure and will be fixed in a future release). +If ISDN_NUMBER is the string "localhost", the eftp.sh scripts tries +to set up a connection to the own computer by means of the isdnloop +driver, for the benefit of your phone bill. + +When eftp has established the connection, it issues the "eftp>" prompt +and waits for commands that will be read from standard input. +If configured before compilation, interactive input can be edited by +means of the GNU readline library. + +The following commands are recognised: + + + +Commands for Listing and Transferring Files + + +dir [PATTERN] + + This corresponds to ETS 300-075 and ETS 300-383 T-DIRECTORY + primitive. It prints a list of files contained in the current + working directory (ETSI calls it the "current filestore"). + PATTERN is a pattern as defined in ETS 300-075 and selects a + subset of those files to be displayed. ETS 300-075 pattern are + different from shell wildcard or regular expressions, but the + pattern "*" matches all filenames as you'd expect. I won't + explain further pattern rules here because most servers don't + recognise any patterns different from "*" anyway. + + If pattern is omitted, the * pattern is assumed. + + Pattern applies to the EUROFILE transfer name of the files, + which is not necessarily identical to the filename itself. + + Likewise, the output of the command does not list the + filenames, but the transfer names of the files and the file + length. Note that only regular files are listed. For listing + subdirectories, there are the list and slist commands. + + +xdir [PATTERN] + + This is similar to the dir command but requests the directory + contents in extended format. In addition to the transfer name, + this will also contain the real name of the file and the time + stamp of the last write access. + + Note that not all servers support directory requests with + extended format. Some of those servers will respond with + a normal directory contents file, others will reject the + request. In the former case, eftp will issue a warning message + and use the transfer name for the file name and use 1970-01-01 + as the last access date. (The eftp4linux server supports + extended directory formats). + + +get TRANSFER_NAME [PATH_NAME] + + This corresponds to the 300-075 T-LOAD primitive and + tries to load the file identified by TRANSFER_NAME + from the remote server and stores it locally using PATH_NAME + as the destination. If PATH_NAME is omitted, TRANSFER_NAME is + also used as the destination name. + + +put [PATH_NAME] TRANSFER_NAME + + This corresponds to the ETS 300-075 T-SAVE primitive and + tries to upload the local file identified by PATH_NAME + to the remote server, using TRANSFER_NAME as the destination. + If PATH_NAME is omitted, TRANSFER_NAME is also used as to + identify the local file. + +mget PATTERN + + get multiple files whose transfer names match PATTERN. PATTERN + is (currently) interpreted a shell glob pattern, not an + ETS 300 075 pattern. + +mput PATTERN + + put multiple files whose names match PATTERN. PATTERN is + interpreted a shell glob pattern, not an ETS 300 075 pattern. + + NOTE: The matched name is also used as the transfer name. + If pattern matched local files whose file name do not form + a valid ETS 300-383 transfer name, the transfer of those + files might fail. + +prompt [on|off] + + If "on", prior to each file transferred by mput or mget, the + user is prompted for confirmation. If no parameter is given + the on/off value is toggled. + + Possible user responses to the prompt: + + y transfer the file + n don't transfer the file and prompt for the next one + +case [on|off] + + If "off", cases are ignored when matching PATTERN in mget and mput. + If parameter is missing, toggle current parameter value. + + This currently does nor work with all versions of libc. + + +Navigation Commands (related to directories) + + These commands are likely to fail because many servers don't + support the navigation facility. (The eftp4linux server, + however, supports this :-) + +cd [DIRECTORY] + + This changes the current working directory ("current + filestore") to DIRECTORY. If DIRECTORY is omitted, + the default directory (this is the one initially entered + when logged in) is changed to. + + This command is likely to fail because many servers don't + support the navigation facility. + +pwd + + This prints the name of the server's current working directory + ("current filestore") to stdout. + +slist + + This corresponds to the 300-383 S-LIST primitive. + It prints a list of the subdirectories contained in the + current working directory. The list items consist of + a so called file store reference followed by the filestore + (directory) name. (The eftp4linux server supports this, but + the filestore references are currently not generated totally + norm conforming.) + + +list + + This corresponds to the ETS 300-383 LIST primitive. + It is similar to the slist command, but prints a list of all + directories of the server. (Even the eftp4linux server does not + support this). + + + +Misc Commands + +msg MESSAGE + + The MESSAGE string is send literally to the remote server + if the server supports it (most servers won't) by means of + the ETS 300-075 T-TYPED_DATA primitive. + + If MESSAGE is ommitted, the client will prompt for the message + string (can currently cause problems as protocol precessing is + currently not performed whil waiting for the user input). + +lcd DIR + + change local working directory to DIR + +! COMMAND-STRING + + execute COMMAND-STRING as a shell command. + +quit + + This will quit the EUROFILE session, close the connection, and + exit the eftp programme. + + +Readline Support +================ + +When eftp is compiled with the CONFIG_EFTP_READLINE option set to "y" +in the configure shell script, command line editing is performed by +means of the readline library. (Thanks to Michael Mauch for adding +this). + +When using the readline code, the terminal might be left in a strange +mode if the program didn't exit properly. In such a case you can +return to the normal terminal mode by running the program "reset", +which is a link to "tset" (see tset(1)).