Add rtape, and updated cbridge as dependency

[Bikeman]

A super easy way to make full or incremental backups of the ITS filesystem is by using :DUMP with a remote tape saver. The big advantage is that you don't have to stop the simulation to mount and unmount "tapes" to the simulated local tape drives, it all can be done from the ITS :DUMP interactively

See https://groups.google.com/g/pidp-10/c/vWG5s2bK5go/m/2poBmSGzAwAJ for a discussion of this.
TL;DNR Summary:

1. For this to work, the cbridge that is currently included in PiDP10 needs to be replaced with a newer version to support a Chaosnet RTAPE server simulated on the Raspi host

2. Currently PiDP10 software installs e.g. mlftp, but not the rtape chaosnet tool. The rtape from https://github.com/Chaosnet/chaosnet-tools has an issue with ITS :DUMP as of the time of writing, see Put error message at right offset Chaosnet/chaosnet-tools#13 (comment)

Once this is fixed (no big deal) it actually works like a charm: I have now tested both full and incremental update to a simulated remote tapedrive on the PI, and it does work and is very useful indeed.

It would also require some mentioning in the PiDP10 documentation of course so people are aware this feature is supported.

I understand Lars in (understandably) against installing new services on the PI, so the documentation would instruct users to start rtape manually when needed.

[larsbrinkhoff]

Can you please post a pull request to the chaosnet-tools repository?

I'm not against installing new services, but it's Oscar's call. Of course, serious consideration about security issues would have to been made. Currently, there is only a Chaos network set up on the local machine. If the network is exposed externally, anyone could use the RTAPE protocol to read and write files from where the rtape server was started.

[Bikeman]

OK the security implication is a good point. To help with mild cases of paranoia, I could add an optional argument to rtape perhaps to allow connections only from a certain chaosnet address (e.g. in our case 177002). If @bictorv doesn't beat me to it I'll make a merge request wrt rtape in chaosnet-tools soonish

[bictorv]

I'm already planning a general firewall functionality of cbridge, where you can specify how to handle RFC/BRD packets for various contact names and combinations of source/dest addresses/subnets. This would not handle e.g. allowing read but not write access to tapes in RTAPE. Deep packet inspection is not in my plans (yet).

[bictorv]

See https://groups.google.com/g/pidp-10/c/vWG5s2bK5go/m/2poBmSGzAwAJ for a discussion of this.

It seems I'm not allowed to see it. Would I need to subscribe to the google group?

[Bikeman]

weird,, not even the group top level?  https://groups.google.com/g/pidp-10 Anyway you might want to join, lots of new potential chaosnet users/developers there hb Gesendet von AOL auf Android Am Sa., Apr. 6, 2024 at 16:38 schrieb Björn ***@***.***>: See https://groups.google.com/g/pidp-10/c/vWG5s2bK5go/m/2poBmSGzAwAJ for a discussion of this. It seems I'm not allowed to see it. Would I need to subscribe to the google group? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bictorv]

What is the subject line of the discussion you referenced? (There seems to be some mess related to which of my google accounts is used when I follow your link.)

[larsbrinkhoff]

It's in the middle of "List of ITS DDT Commands".

[bictorv]

I'm already planning a general firewall functionality of cbridge, where you can specify how to handle RFC/BRD packets for various contact names and combinations of source/dest addresses/subnets. This would not handle e.g. allowing read but not write access to tapes in RTAPE. Deep packet inspection is not in my plans (yet).

Be my test pilot(s), and try out the new firewall branch of cbridge! Feedback welcome!

[larsbrinkhoff]

@Bikeman, would you please take a look at https://gunkies.org/wiki/Chaos_RTAPE_protocol and see if it agrees with your recent understanding of the RTAPE protocol?

[Bikeman]

@Bikeman, would you please take a look at https://gunkies.org/wiki/Chaos_RTAPE_protocol and see if it agrees with your recent understanding of the RTAPE protocol?

No, this doesn't agree. The "gunkies" version allows status information messages that are shorter than 36. bytes which is the minimum length that DUMP allows without erroring out with a "too short" error message.

Our latest version that is now working with ITS DUMP differs in the last two lines of the table :

34 | 2 | flags
36 | ? | Optional error message

Would be cool to find a contemporary document that is describing the protocol.

[bictorv]

What's missing is that the drive name field is always 16. bytes (and "n" says how many of them are valid).

Would be cool to find a contemporary document that is describing the protocol.

It's what the "gunkies document" is trying to be, I suppose?

[Bikeman]

Ah sorry for the ambiguity, I meant to say contemporary wrt. the PDP-10, so vintage documents.

[larsbrinkhoff]

I updated the last part of the table thusly:

Offset	Size	Description
17	1	Length of drive name
18	16	Name of drive
34	2	Flags
36	?	Optional error message