Well, it's been a long time project, but I'm happy to finally announce a more public initial release of TCP/IP for RSX-11M-PLUS.
This is the result of over 20 years of development. Needless to say, I've been doing a lot of things over the years, and this code have been through four reimplementations over the years.
What I now release is something that I believe is a nice and useful piece of software. I am aware of the fact that most people do not use these machines any longer, but if someone actually wants to talk to me about support for this or other RSX software, let me know.
Also, feel free to spread this information to anyone who might be interested, anywhere.
So - what is in this release?
It is a complete implementation of ARP, IP, UDP, and TCP for RSX-11M-PLUS. It has been tested on RSX-11M-PLUS V4.6, but should work on any V4 release. There might be some small tweaks or fixes required, but nothing major.
It do require a system with split I/D-space, or else at least the TCP part will not fit.
For Unibus machines, it should be possible to run without any additional software except what is in a base RSX distribution.
For Q-bus machines, DECnet is required for ethernet networking.
The TCP/IP stack can co-exist with DECnet.
Some utilities also utilize RMS for file access.
A bunch of tools, utilities and libraries are also included. These include:
. IFCONFIG network configuration tool.
. NETSTAT network information tool.
. PING
. TRACEROUTE
. DNS client
. FTP daemon
. FTP client
. HTTP server
. TELNET client (rudimentary)
. TFTP client
. TFTP server
. INET server that can do SINK, ECHO, DAYTIME, QUOTE, and IDENT
. NTP client
. LPR client that sits in the queue manager (rudimentary)
. FORTRAN-77 library
. BASIC+2 library
. PDP-11 C library
The implementation fulfills most of the requirements put forth in RFC 1122. There are a few limitations because of restrictions in the PDP-11, but none of them should really cause any problems.
Documentation is still on the thin side, but example configs are also provided, along with installation scripts.
A bunch of test programs and example programs are also included, as well as the sources of all tools and libraries.
The TCP/IP stack itself only comes in binary form.
All tools are also included precompiled in the distribution, so an installation only have to build the stack itself for your system, and then you should be ready to go.
The API only have a slight resemblance to the Unix sockets API. However, if someone sits down to write code to use TCP/IP under RSX, I'm sure they will discover that it is extremely easy to use the libraries, or the basic functions.
The TCP/IP implementation is mostly written as device drivers. This also have some other interesting implications, such as it is possible to access TCP as a normal file. You can, for instance do something similar to the Unix netcat command by issuing the MCR command:
> PIP TI:=TC:"foo.com";4711
which would open a connection to foo.com, on port 4711, and any data sent from that machine will be shown on the terminal.
The resources used by TCP/IP are modest. A memory area (size selectable at generation/startup) is used internally. The amount of memory in the private pool limits the amount of data that can be buffered. Normal pool is used in a small quantity for each TCP port that is open.
People are welcome to play around with this, and make improvements. Contributions of code is most welcome.
There are still lots of things to do. The programs marked as rudimentary should be rewritten.
The most obvious thing still missing is a telnet daemon, which probably is my next step.
However, the reason for now announcing the release is that it can finally be distributed natively from an RSX host.
The main locations to download the TCP/IP for RSX are:
Madame.Update.UU.SE (anonymous ftp).
This is one of my development systems for this software. It runs under E11, and if things are down, I blame E11. :-)
When connected, you are already in the right directory. There is both an RL02 disk image there, which can be downloaded by anyone. If you happen to have an RSX system which you are conneting from, you can also try getting the BQTCP.TAP tape image. Such an image will not transport cleanly to a non-RSX system, however. Sorry.
ftp.Update.UU.SE (anonymous ftp) - /pub/pdp11/rsx/tcpip
The disk image is normally duplicated to ftp.update.uu.se as well, so the same file can be found there.
I hope some people will find this useful/amusing. :-)
Johnny Billquist
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I could use the money but don't know anything about even small modifications to Android programs, even if you do have details of the server / protocol.
Also my written Swedish is far too rusty.
Sampsa
On 11 Jan 2015, at 23:16, Johnny Billquist <bqt at softjar.se> wrote:
Sorry guys. I accidentally sent this to the wrong list. :-)
I guess not too many people speak Swedish here.
Johnny
On 2015-01-11 22:14, Johnny Billquist wrote:
Hej. Finns det n gon h r, eller n gon som k nner n gon annan som har
erfarenhet av utevckling f r Android?
Jag har ett litet jobb som skulle beh va g ras. Sj lv har jag aldrig
mekat med Android, s jag kan nog inte g ra det p rimlig tid sj lv.
Det handlar om en mindre modifiering av ett existerande program. Sj lva
modifieringen skulle jag gissa handlar om ett par rader kod, men man
beh ver orientera sig i koden, bygga, testa, och vara ok p att om allt
fungerar bra s kan det bli mer jobb senare. (Fast notera att jag inte
har koll p koden, s min gissning handlar bara om vad jag inbillar mig
utifr n den ndring som nskas.)
Jag hj lper g rna till med detaljer och information till den som tar sig
an det. Klienten p Android pratar med en server som jag har lite mer
koll p .
Skulle tro att det blir ett fast pris p jobbet. Men den ekonomiska
sidan kan jag ta med personer som r intresserade.
H r av er om det verkar vara n got.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Sorry guys. I accidentally sent this to the wrong list. :-)
I guess not too many people speak Swedish here.
Johnny
On 2015-01-11 22:14, Johnny Billquist wrote:
Hej. Finns det n gon h r, eller n gon som k nner n gon annan som har
erfarenhet av utevckling f r Android?
Jag har ett litet jobb som skulle beh va g ras. Sj lv har jag aldrig
mekat med Android, s jag kan nog inte g ra det p rimlig tid sj lv.
Det handlar om en mindre modifiering av ett existerande program. Sj lva
modifieringen skulle jag gissa handlar om ett par rader kod, men man
beh ver orientera sig i koden, bygga, testa, och vara ok p att om allt
fungerar bra s kan det bli mer jobb senare. (Fast notera att jag inte
har koll p koden, s min gissning handlar bara om vad jag inbillar mig
utifr n den ndring som nskas.)
Jag hj lper g rna till med detaljer och information till den som tar sig
an det. Klienten p Android pratar med en server som jag har lite mer
koll p .
Skulle tro att det blir ett fast pris p jobbet. Men den ekonomiska
sidan kan jag ta med personer som r intresserade.
H r av er om det verkar vara n got.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hej. Finns det n gon h r, eller n gon som k nner n gon annan som har erfarenhet av utevckling f r Android?
Jag har ett litet jobb som skulle beh va g ras. Sj lv har jag aldrig mekat med Android, s jag kan nog inte g ra det p rimlig tid sj lv.
Det handlar om en mindre modifiering av ett existerande program. Sj lva modifieringen skulle jag gissa handlar om ett par rader kod, men man beh ver orientera sig i koden, bygga, testa, och vara ok p att om allt fungerar bra s kan det bli mer jobb senare. (Fast notera att jag inte har koll p koden, s min gissning handlar bara om vad jag inbillar mig utifr n den ndring som nskas.)
Jag hj lper g rna till med detaljer och information till den som tar sig an det. Klienten p Android pratar med en server som jag har lite mer koll p .
Skulle tro att det blir ett fast pris p jobbet. Men den ekonomiska sidan kan jag ta med personer som r intresserade.
H r av er om det verkar vara n got.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Thanks everyone for the offers. Right now I need to write some more code in order to test things.
I'll get back with more specific wishes in a few days.
Johnny
On 2015-01-09 01:36, Steve Davidson wrote:
I can enable Multinet ftp on SG1:: if necessary. I will send you the address offline...
-Steve
Sent from my iPhone
On Jan 8, 2015, at 17:09, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:
On Thursday, January 08, 2015 at 1:41 PM, Johnny Billquist wrote:
On 2015-01-08 21:57, Mark Pizzolato - Info Comm wrote:
On Thursday, January 08, 2015 at 12:22 PM, Johnny Billquist wrote:
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try
VMS, on the client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one
from a plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a
DIR /FULL shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
When I looked earlier there were a lot of zeros. Guessing is probably not
worth it. I think it would be more productive to dig through the source to the
HGFTP server. The source is in the HGFTP033.F saveset within the previously
mentioned zip file. The module FTP_FTON.B32 seems to contain the
relevant magic:
Thanks.
If you don't have the system to unpack the zip and extract these files from
the saveset I'll be glad to send them directly. Otherwise I'm done digging.
This should be enough. The thing is, I was expecting it to be pretty much this.
It's just a couple of magic values that needed to be identified.
You have done more than enough. I do not expect that you have to do any
more. I eventually would just like to test/verify this against a live system. This
weekend probably...
That might be more of a problem... I don't have a MultiNet system publicly exposed.
Hmmm... But Process software does. They ones who ended up with MultiNet:
ftp://ftp.process.com
- Mark
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I can enable Multinet ftp on SG1:: if necessary. I will send you the address offline...
-Steve
Sent from my iPhone
On Jan 8, 2015, at 17:09, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:
On Thursday, January 08, 2015 at 1:41 PM, Johnny Billquist wrote:
On 2015-01-08 21:57, Mark Pizzolato - Info Comm wrote:
On Thursday, January 08, 2015 at 12:22 PM, Johnny Billquist wrote:
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try
VMS, on the client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one
from a plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a
DIR /FULL shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
When I looked earlier there were a lot of zeros. Guessing is probably not
worth it. I think it would be more productive to dig through the source to the
HGFTP server. The source is in the HGFTP033.F saveset within the previously
mentioned zip file. The module FTP_FTON.B32 seems to contain the
relevant magic:
Thanks.
If you don't have the system to unpack the zip and extract these files from
the saveset I'll be glad to send them directly. Otherwise I'm done digging.
This should be enough. The thing is, I was expecting it to be pretty much this.
It's just a couple of magic values that needed to be identified.
You have done more than enough. I do not expect that you have to do any
more. I eventually would just like to test/verify this against a live system. This
weekend probably...
That might be more of a problem... I don't have a MultiNet system publicly exposed.
Hmmm... But Process software does. They ones who ended up with MultiNet:
ftp://ftp.process.com
- Mark
On Thursday, January 08, 2015 at 1:41 PM, Johnny Billquist wrote:
On 2015-01-08 21:57, Mark Pizzolato - Info Comm wrote:
On Thursday, January 08, 2015 at 12:22 PM, Johnny Billquist wrote:
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try
VMS, on the client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one
from a plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a
DIR /FULL shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
When I looked earlier there were a lot of zeros. Guessing is probably not
worth it. I think it would be more productive to dig through the source to the
HGFTP server. The source is in the HGFTP033.F saveset within the previously
mentioned zip file. The module FTP_FTON.B32 seems to contain the
relevant magic:
Thanks.
If you don't have the system to unpack the zip and extract these files from
the saveset I'll be glad to send them directly. Otherwise I'm done digging.
This should be enough. The thing is, I was expecting it to be pretty much this.
It's just a couple of magic values that needed to be identified.
You have done more than enough. I do not expect that you have to do any
more. I eventually would just like to test/verify this against a live system. This
weekend probably...
That might be more of a problem... I don't have a MultiNet system publicly exposed.
Hmmm... But Process software does. They ones who ended up with MultiNet:
ftp://ftp.process.com
- Mark
On 2015-01-08 21:57, Mark Pizzolato - Info Comm wrote:
On Thursday, January 08, 2015 at 12:22 PM, Johnny Billquist wrote:
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try VMS, on the
client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one from a
plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a DIR /FULL
shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
When I looked earlier there were a lot of zeros. Guessing is probably not worth it. I think it would be more productive to dig through the source to the HGFTP server. The source is in the HGFTP033.F saveset within the previously mentioned zip file. The module FTP_FTON.B32 seems to contain the relevant magic:
Thanks.
If you don't have the system to unpack the zip and extract these files from the saveset I'll be glad to send them directly. Otherwise I'm done digging.
This should be enough. The thing is, I was expecting it to be pretty much this. It's just a couple of magic values that needed to be identified.
You have done more than enough. I do not expect that you have to do any more. I eventually would just like to test/verify this against a live system. This weekend probably...
Johnny
On Thursday, January 08, 2015 at 12:22 PM, Johnny Billquist wrote:
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try VMS, on the
client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one from a
plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a DIR /FULL
shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
When I looked earlier there were a lot of zeros. Guessing is probably not worth it. I think it would be more productive to dig through the source to the HGFTP server. The source is in the HGFTP033.F saveset within the previously mentioned zip file. The module FTP_FTON.B32 seems to contain the relevant magic:
fileattr_buffer[FATTR_L_VERSION] = FATTR_C_FILEATTR_VERSION;
fileattr_buffer[FATTR_L_LENGTH] = FATTR_S_FATTRDEF;
fileattr_buffer[FATTR_L_FAB_L_ALQ] = .in_fab[FAB$L_ALQ];
fileattr_buffer[FATTR_L_FAB_L_FOP] = .in_fab[FAB$L_FOP];
fileattr_buffer[FATTR_L_FAB_L_MRN] = .in_fab[FAB$L_MRN];
fileattr_buffer[FATTR_W_FAB_W_DEQ] = .in_fab[FAB$W_DEQ];
fileattr_buffer[FATTR_W_FAB_W_MRS] = .in_fab[FAB$W_MRS];
fileattr_buffer[FATTR_B_FAB_B_ORG] = .in_fab[FAB$B_ORG];
fileattr_buffer[FATTR_B_FAB_B_RAT] = .in_fab[FAB$B_RAT];
fileattr_buffer[FATTR_B_FAB_B_RFM] = .in_fab[FAB$B_RFM];
fileattr_buffer[FATTR_B_FAB_B_BKS] = .in_fab[FAB$B_BKS];
fileattr_buffer[FATTR_B_FAB_B_FSZ] = .in_fab[FAB$B_FSZ];
fileattr_buffer[FATTR_B_XAB_B_RFO] = .in_xabfhc[XAB$B_RFO];
fileattr_buffer[FATTR_W_XAB_W_LRL] = .in_xabfhc[XAB$W_LRL];
fileattr_buffer[FATTR_B_XAB_B_BKZ] = .in_xabfhc[XAB$B_BKZ];
fileattr_buffer[FATTR_B_XAB_B_HSZ] = .in_xabfhc[XAB$B_HSZ];
fileattr_buffer[FATTR_W_XAB_W_MRZ] = .in_xabfhc[XAB$W_MRZ];
fileattr_buffer[FATTR_W_XAB_W_DXQ] = .in_xabfhc[XAB$W_DXQ];
fileattr_buffer[FATTR_W_XAB_W_GBC] = .in_xabfhc[XAB$W_GBC];
fileattr_buffer[FATTR_B_XAB_B_ATR] = .in_xabfhc[XAB$B_ATR];
fileattr_buffer[FATTR_B_FAB_B_RTV] = .in_fab[FAB$B_RTV];
fileattr_buffer[FATTR_W_FAB_W_BLS] = .in_fab[FAB$W_BLS];
Where in FTP.R32 the FATTR structure seems to be defined:
_DEF(FATTR)
FATTR_L_VERSION = _LONG,
FATTR_L_LENGTH = _LONG,
FATTR_L_FAB_L_ALQ = _LONG,
FATTR_L_FAB_L_FOP = _LONG,
FATTR_L_FAB_L_MRN = _LONG,
FATTR_W_FAB_W_DEQ = _WORD,
FATTR_W_FAB_W_MRS = _WORD,
FATTR_B_FAB_B_ORG = _BYTE,
FATTR_B_FAB_B_RAT = _BYTE,
FATTR_B_FAB_B_RFM = _BYTE,
FATTR_B_FAB_B_BKS = _BYTE,
FATTR_B_FAB_B_FSZ = _BYTE,
FATTR_B_XAB_B_RFO = _BYTE,
FATTR_W_XAB_W_LRL = _WORD,
FATTR_B_XAB_B_BKZ = _BYTE,
FATTR_B_XAB_B_HSZ = _BYTE,
FATTR_W_XAB_W_MRZ = _WORD,
FATTR_W_XAB_W_DXQ = _WORD,
FATTR_W_XAB_W_GBC = _WORD,
FATTR_B_XAB_B_ATR = _BYTE,
FATTR_B_FAB_B_RTV = _BYTE,
FATTR_W_FAB_W_BLS = _WORD,
FATTR_W_XAB_SEMANTICS_LENGTH= _WORD, ! sizeof(xab_stored_semantics)
FATTR_W_XFILL = _WORD, ! Preserve QUAD alignment
FATTR_X_XAB_STORED_SEMANTICS= _BYTES(XAB$C_SEMANTICS_MAX_LEN)
_ENDDEF(FATTR);
This implies that for some files there are extended attributes appended.
If you don't have the system to unpack the zip and extract these files from the saveset I'll be glad to send them directly. Otherwise I'm done digging.
- Mark
On 2015-01-08 21:06, Mark Pizzolato - Info Comm wrote:
On Thursday, January 08, 2015 at 10:44 AM. Johnny Billquist wrote:
Aha! That is really good information. Now I just wonder if it always tries this
trick, or only if the other side identifies itself as a VMS system. Could you do
the same test against a Unix system and see if it tries the STRU command
there too?
The binary blob is what I need to figure out next...
As of now, Text transfers to and from RSX works fine, and I've extended the
directory output a little. I'm wondering if I should bother trying to fool things
like web browsers next, as they also tries to be clever and tries to
understand a Unix-style directory output.
What I see is that the VMS FTP client sends the "STRU O VMS" command immediately after the connection is established (BEFORE the login is established).
Here is a conversation with a VMS (MultiNet) FTP client talking to a VMS (Multinet) FTP Server:
[...]
Even better. This I can work with, and I can do the same...
Actually, I'll be tricky and start with RSX, and if that fails, try VMS, on the client side. While the server should understand both.
Now I just need to figure out the binary blob. Could you capture one from a plain text file transfer for me? I think that should be enough.
(Actually, any file, as long as you can also provide me with what a DIR /FULL shows for the file.)
I have a very strong suspicion what is in there, I just want to verify it.
Johnny
