Updated Mon Dec 30 22:03:45 2002
Popularity
| Matt J. Gumbley - http://www.gumbley.demon.co.uk |
The Linux NCP-Link Project
Abstract
Psion palmtop computers typically communicate with a PC (or Mac) using Psion's PsiWin (PsiMac) product. (Or RCOM, or MCLINK). These products provide three communications protocols running over the serial link: a logical link protocol, a data transport and multiplexing protocol and a file server protocol. PsiWin also provides application-specific data-convertors. There is no corresponding product for Linux. Products exist which require specialised daemons running on the Psion, but none utilise the built in protocols. This project attempts to provide Linux support for the three built-in protocols (so you can see your Linux system from your Psion), and a Linux filesystem driver for the remote file server protocol (So you can mount the Psion's file systems on your Linux system). Of course, with Linux being available on more than one architecture, this software will run anywhere you have Linux. It has been tested on Intel and Sparc Linux, and can be ported easily to any UNIX.
Table Of Contents
- 1 Project Status
- 2 Introduction
- 3 Appendix A: Protocol Documentation
1 Project Status
I've been beaten to it (again) - Philip Proudman released his stack (plp) and Fritz Elfert extended it (plptools). So, I've abandoned work on my own protocol stack, and am concentrating on extending plptools. My efforts towards this can be found here.
The only part of this project likely to survive is the NCP protocol analyser,
and the Linux Kernel modules - I'll create new pages for these as and when I
find time.
2 Introduction
2.1 Intended readership
The first part of this document is intended for all users of the software. The
appendices are for propeller heads.
2.2 Download Information
Currently we have version 0.01, which, as you'll be able to see from the version
number, is the first release. So, expect something buggy and unfinished. In
fact, it isn't finished at all, and won't actually do much, but it's a start.
Release 0.02 on hold.
What may be of use to you (if you're a developer) are the scope and ncpscope programs, contained in the package. They are a general-purpose RS232 line monitor/logger (This is now a separate package - see scope for more details) - and a PLP/NCP/RFSV protocol analyser. The first is relatively finished, the second isn't, but still very useful. There is also a captured session, created by scope, when I was copying files etc. between my Psion 3c and PsiWin1.1. Run this through ncpscope to find out what's going on...
I'll continue refining ncpscope, so check back here from time to time...
I've crashed my Psion 3c several times during development of my driver program (not scope or ncpscope) - once, erasing the entire internal ramdrive, otherwise just resetting it, requiring a re-installation of icons and preferences.
This surprised me somewhat - I can understand my software being buggy, but it shouldn't crash the remote system. (I'm told that if a loadable device driver panics, it causes a SIBO kernel fault. Sounds suspiciously like a reboot to me!)
You can grab it here: linux-ncp-0.01.tar.gz.
Although the ncp program source is included in this package, it won't build
(since it's not finished yet). All you get is scope and ncpscope.
Feedback on this software is most welcome, either to me directly, or to the
following mailing list...
2.3 Mailing List
The Linux-Psion mailing list has been set up to discuss what happens when you
combine a Psion and a Linux system. This NCP project is one of its first fruits
(AFAIK).
To subscribe, send a message to majordomo@geekstuff.co.uk,
containing the message subscribe linux-psion.
2.4 References and Acknowledgements
This software could not have been possible without the efforts of others - I'd
particularly like to thank:
- Olaf Flebbe and Michael Pieper, for their assistance in documenting the Psion Link Protocol. The appendix of this document is a condensation of their work. We all owe Olaf and Michael a big "danke" for their work!
- The maintainers of the linux-psion@geekstuff.co.uk mailing list, and the members of that list, for giving me the impetus to start this project.
- Linus Torvalds, Richard Stallman (and a cast of thousands), for the Linux Kernel and GNU project.
- Bram Moolenar et al for "vi improved" -- the ultimate editor for those who don't yet need Emacs ;-)
- Red Hat, for their splendid distribution for Intel and Sparc.
- Psion, for the Series 3.
For information on writing Linux Device Drivers/Filesystems/Line Disciplines, I have to thank:
- Allessandro Rubini, for "Writing Linux Device Drivers",
- David A. Rusling, for "The Linux Kernel",
- Paul Fulghum of Microgate Corporation, for releasing the source code to their Line Discipline driver under the GPL.
- Linus Torvalds, et al. for the Linux Kernel
3 Appendix A: Protocol Documentation
This appendix contains an overview of the protocols in use, followed by more technical descriptions of the frame formats.
It isn't finished.
3.1 Overview of the remote link
The remote link is a four-layer protocol:
- The physical layer concerns the serial driver, the baud rate used, framing etc.
- The logical link layer, which is denoted in the references as PLP (Psion Link Protocol), which provides a reliable link for the...
- Transport and Multiplexing layer, known as NCP (Network Control Protocol). This in turn is used by the...
- Application layer, typically Psion's remote file server (RFSV), or the LINK program. It can also be used by other user applications.
So, the first phase will handle physical, logical, network layers, and provide a LINK server and SYS$RFSV server. The second phase will provide a RFSV client that maps Linux VFS requests into RFSV protocol frames, routed over NCP/PLP.
I may separate PLP and NCP into a line discipline module - I haven't
decided yet.
3.2 The PLP Protocol
3.2.1 Description
The PLP protocol (and NCP protocol) is implemented in a process called
SYS$NCP on the Psion.
PLP is a simple protocol, designed to fit into small amounts of memory, based on the MicroCom Network Protocol (MNP). It provides a symmetric full-duplex link, with error-detection being aided by the CCITT 16-bit CRC, with polynomial x16+x12+x5+1 (i.e. starting value 0x1021).
Frames are numbered, multiple retransmissions are allowed, and the the window size is only one, so the link is probably not very efficient (but it doesn't need to be).
Every frame that is sent must be acknowledged. If no acknowledgement is received within some as-yet unascertained tineout period, the frame is resent.
Frames may be up to 300 bytes, and the frame size is variable. PLP (or is it NCP?) will segment large transmissions into 300-byte chunks as necessary.
PLP is a data transfer protocol, not a file transfer protocol - additional
application layers need to be added which supply file access and management
facilities. PLP protocol passes undifferentiated bytes.
3.2.2 Frame Formats
Each packet is of the format:
SYN HEADER TYPE DATA FOOTER CRC
Where:
- SYN is ASCII 0x16
- The HEADER is composed of the bytes 0x10, 0x02
- The TYPE is one of:
- 0x0? : ACKNOWLEDGEMENT of a previously-sent DATA frame. The low nibble (?) contains the sequence number of the frame being acknowledged. There is no DATA section in an ACKNOWLEDGEMENT frame. Frame numbers are modulo 15 (they wrap to zero at 0x0F)
- 0x1? : DISCONNECT. Sent when the Psion's remote link is turned off (Psion-L) The low nibble (?) is unspecified, and is zero.
- 0x2? : LINK REQUEST. Requests a new link session. When responding to this, an ACKNOWLEDGEMENT frame must be sent with the sequence number reset to zero. There is no DATA section in a LINK REQUEST.
- 0x3? : DATA. The DATA part of the frame holds an NCP frame. The low nibble (?) contains the sequence number, and this frame must be replied to with an ACKNOWLEDGEMENT frame containing the same sequence number. Since only one frame can remain "on the wire", unacknowledged, the process or protocol layer sending data must block until an acknowledgement has been received. CRC errors will result in no acknowledgement being sent. The retransmission timeout period is unknown.
- The FOOTER is always 0x10, 0x03
- The CRC is the CCITT 16-bit CRC. It is calculated from the TYPE byte to the end of the DATA part, and does not include SYN, HEADER or FOOTER.
3.3 The NCP Protocol
3.3.1 Description
Again, this is implemented in the SYS$NCP process on the Psion.Once a physical connection has been made (the driver sees the DSR signal, i.e. the remote side's DTR), the Psion's PLP layer will send a LINK REQUEST message to the PC, which must be acknowledged.
Then, the Psion NCP layer exchanges logon messages with the remote side. The logon messages contain a version number and the time at which the NCP layer started. This allows connections to be re-started in the event of a logical or physical layer failure. SIBO computers tend to reply with a version3, whereas PsiWin is version 2.
These logon messages are sent as NCON_MSG_NCP_INFO frames. The Psion's frame is received and acknowledged, and then the PC must send one, which will be acknowledged. The NCP link is then active.
NCP provides eight logical channels, multiplexed over the physical link. Channel 0 is used by the NCP protocol driver itself, to communicate with its remote counterpart, and is the only channel that does not have to be explicity connected to.
Applications talk over the remote link, over a given channel. NCP talks to NCP over channel zero. For instance, the timestamp frames explained above are sent over channel 0. The remaining seven channels are available for applications (Although LINK and SYS$RFSV take up two, automatically).
Applications can send frames of arbitrary sizes; NCP performs
fragmentation and reassembly.
3.3.2 Frame Formats
Each packet is encapsulated inside a PLP DATA (0x3?) frame, and so the DATA
part of the PLP frame is of the format:
TX-CHANNEL RX-CHANNEL DATA
Where:
- TX-CHANNEL is a byte indicating the channel number of the sending process
- RX-CHANNEL is a byte indicating the channel number of the receiving process (The channel that this message is concerning, as in a CONNECT to channel 3, this byte would hold 0x03)
- The DATA is only of consequence to NCP if the TX-CHANNEL is 0, i.e. if this is a control frame for the remote NCP layer to process. If the TX-CHANNEL is not zero, then this data is passed to the process bound to that channel. For instance, SYS$RFSV or LINK.
Need to finish description of NCP, and start on...
3.4 The LINK application
3.4.1 Description
The LINK application exists on Series 3 as part of the System Screen -
allowing the user to turn the link on and off, to set the baud rate, etc.
Changes in the state of the underlying NCP protocol are monitored behind the
scenes on a Series 3. The user is informed if any major changes occur. The
LINK application performs another major function: it sets up the remote
file server as an application talking over NCP. This process is
SYS$RFSV. LINK adds the REM:: file system node to the
file server, so that applications can access files using the familiar file
system calls.
LINK also handles IPC (Inter-Process Communication) messages. Applications may send the following messages to the LINK process:
- LINKMSG_TERMINATE - terminate the LINK application, close the SYS$RFSV, and close SYS$NCP.
- LINKMSG_LOADREMOTE - load a process on the remote system. The remote side will load the program named in the protocol frame, and this process will then open an NCP channel. The remote LINK then sends the process ID and full process name back to the local LINK, which passes back the name and process ID to the application on the local machine that initiated the LINKMSG_LOADREMOTE.
- LINKMSG_CONFIG - pass information to the remote LINK, for use during a device driver reconfiguration.
3.4.2 Frame Formats
Don't know these yet.3.5 The SYS$RFSV application
3.5.1 Description
The Series 3 LINK application is responsible for opening the PLP/NCP link, and starting the SYS$RFSV process, which acts as a server for RFSV messages. LINK will create a filesystem node called REM:: which (presumably) receives filesystem access requests from the OS, these get translated into RFSV requests, sent over the NCP link to the remote RFSV process which will perform the necessary filesystem accesses and respond.
In phase I of this implementation, only the RFSV server will be provided,
allowing you to access the Linux filesystem from your Psion. Phase II is
to write a userfs daemon which converts userfs/VFS requests into RFSV frames,
channeled over NCP so that the Linux system can mount the Psion's drives. i.e.
an RFSV client.
3.5.2 Frame Formats
Each packet is encapsulated inside a NCP DATA frame, sent between the
appropriate local and remote channels, and so the DATA
part of the NCP frame is of the format:
FRAME-NUMBER COMMAND SIZE DATA
Where:
- FRAME-NUMBER is a byte, indicating a fragment number in a large transmission. For small (< 300 bytes) frames, the FRAME-NUMBER is 1. Larger operations, such as a large RFSV_FWRITE operation may fragment their data over multiple frames, starting with a high FRAME-NUMBER (say, 5), and decrementing this with each frame, until it reaches 1, which is the final frame. Note that frames with a FRAME-NUMBER > 1 will not contain any COMMAND - the protocol remembers that it is in a write, and just needs the data.
- COMMAND is a little-endian word as shown in the table below.
- SIZE is a little-endian word giving the amount of data that follows in the DATA area.
- DATA is data required by the command in question, of variable format.
To be continued...
3.6 Other user applications
To be continued...
| Matt J. Gumbley - matt <at> gumbley <dot> demon <dot> co <dot> uk |