Envoy source and availability

[olsen]

It’s old and hackish anyways.

It is old, but it is not that terrible. The important part which Envoy is built upon (nipc.library) has not aged gracefully, but Envoy 2.x and 3.1 have improved it. Its original limitations did not go away, though. Just like a TCP/IP stack, Envoy assumes it has complete ownership of the configured NICs and it will not play nice with others ("my way or the highway"). I think that this could be resolved by implementing an nipc.library which delegates all the UDP traffic wrangling to bsdsocket.library (it could happen). The "small catch" being that the modern Envoy protocols are wholly undocumented. Envoy 1.6 (from 1994) may not be interoperable with the more recent versions.

I still think the Envoy architecture is a pretty sweet design, but I do wonder how well the "reliable datagram protocol" of 1992 fares today. There's no documentation on its origins, let alone if there's any relation to the other n+1 curiously named "reliable datagram protocol" versions of that era. Remembering how quickly Envoy could freeze in a 1993 10BASE2 LAN, I reckon there's still work to be done to research how resilient the protocol really is. The members of the Amiga networking group were either reassigned or dismissed before Envoy could have matured.

Customary gratuitous rant which can be safely ignored: Envoy is not a file sharing or printer sharing solution. These services merely build upon the underlying reliable UDP protocol which nipc.library handles. Envoy is a platform which provides limited authentication and security (in 1992 everything was so simple), auto-configuring peer-to-peer networking without a central authority and enable data exchange between the clients. You could build distributed computing applications using that platform.

[olsen]

So, which is it? "share layer 3 with other stacks without clashing" or "not play nice with others"?

One quite profound "clash" that I recall, is that of what UID 0 is.

The Envoy version for which I saw the source code talks directly to the SANA-II device driver. This is a problem because Envoy assumes that every IP or ARP frame which is transmitted is intended for its use. If a TCP/IP stack on the same machine uses the same SANA-II device driver, Envoy and the TCP/IP stack will grab the next available frame, being unable to check first if it was intended for them.

While you could make use of the SANA-II S2_PacketFilter option to figure out if the source or destination port number is 376 in the IP frame, the original Envoy did not support this option (this was added with Envoy 2.0, if memory serves). The bigger problem are the ARP frames. ARP replies will get read by Envoy or the TCP/IP stack, whoever gets lucky first. The S2_PacketFilter option is no help here either, since the SANA-II device has to offer each frame to every client until one says "it's mine". The filter works well for unicast, but for ARP replies which are broadcast there could be unexpected behaviour, such as the SANA-II driver not implementing the S2_PacketFilter option correctly.

Hiking the Envoy UDP traffic to how the TCP/IP stack does this would solve this overlap in responsibilities. Right now I don't see much of an alternative.

[olsen]

So are we approaching “hackish” yet?

As I wrote, there is no wiggle room for changes to be made in how Envoy deals with SANA-II devices shared by another IP protocol stack (could be the Oxxi ACS client, could be AmiTCP) when broadcast ARP replies enter the picture. Whoever queued the first S2_READ command will deprive the other stack from learning about the ARP reply's message.

In my opinion, a TCP/IP stack as the means to handle ARP and UDP for Envoy would be in the best position to solve this problem because we still have more than one such stack which is still being maintained and developed. It could also deal well with SANA-II devices which do not implement the S2_PacketFilter option, or which implement it incorrectly.

Because the ownership of the Envoy code as it was in 1992-1994 and beyond is complex, I'm just blowing soap bubbles here   Could be that there will come a time when Envoy might make a comeback and one hypothetical way to solve the IP and ARP frame sharing issue might come in handy.

[olsen]

@kolla

You seem to be unable to differentiate between versions 1, 2 and 3. Olsen is talking about version 1. Perhaps you have reading comprehension issues. I would see a doctor if I were you.

As far as I know, Envoy versions 2 and 3 still cannot share the same SANA-II device with AmiTCP, INet-225, Miami, Roadshow, etc. unless you change the frame types for IP and ARP from 2048 and 2054, respectively, to something else.

While versions 2 and 3 are improvements over their precursors, it should not be necessary to tinker with the frame types. There is little harm in this, though, e.g. 2049 and 2055 are presently tagged as "unavailable" or "private" (see https://standards-oui.ieee.org/ethertype/eth.txt).

I would like to see what Envoy does (or attempts to do) implemented robustly. We have nothing comparable to it today, as far as I can tell. What we have is no longer being sold, maintained or developed and there is no replacement for it.

[olsen]

@olsen

On a slightly related note, with OS 3.2...
- what do C:Owner and C:Group actually do?

They set up which specific user and which members of a specific group may access the files, directories, etc. on a volume you control and which is made available for use through a networked file system that enforces these access controls. One example of this kind of file system being the one implemented by the Envoy filesystem.service, which in turn draws upon the local Envoy user and group database via accounts.library.

Basically, "Owner" and "Group" work much like "Protect" does, except that they change the FileInfoBlock.fib_User and FileInfoBlock.fib_Group information of the directories, files, etc. in question.

- what do C:List LFORMAT %U and %G actually show?

They show the name of the user and group, respectively, who/which may have access rights for the respective file, directory, etc.

It's the file system's business to translate the numeric IDs stored in the FileInfoBlock.fib_User and FileInfoBlock.fib_Group into human-readable information. If this is a networked file system, such as exported by Envoy's filesystem.service, then the mapping between the numeric IDs and their associated names is again performed through accounts.library.

If the file system cannot translate the numeric IDs for user and/or group, then the "List" command will just show the numbers as a fall-back.

What user/group database is supposed to be in place here? Where is this supposed to go?

If this is Envoy's filesystem.service providing access, you would first populate its database through the "Accounts Manager" tool, then assign the access rights for the local volume which you want to export.

Integration with Roadshow usergroup.library? Old MuFS? Does Amiga need equivalent of nsswitch?

The way this was designed, it's the network file system which needs to enforce the access rights. Because the client has to be granted permission to access the exported files, directories, etc. the file system server can effectively deny access.

So much for theory. The hashing algorithm behind the Envoy user/group database is very weak and could be cracked easily. Which is probably no surprise, given how little was known about one-way hash functions back in the day outside the circle of security experts. Deploying a Unix-like password hash function scheme based on DES in 1992 would have been a real firecracker. At about that time, there were two BSD 4.4Lite-2 source code variants, the domestic and the export version. Only the weakened export version was deemed "safe". So, no fancy password hash function for Envoy

I have no idea how effective MuFS actually was/is. The Amiga operating system is single user by default because the kind of controls a multi-user operating system provides would have been hard to implement without memory protection. Costly, too, since it would have had to be built around dedicated hardware (such as the Sun 2/3 made use of) making the entire system run more slowly (how does that fit into the feature set of a game machine?). Retrofitting security onto an operating system not designed to support it is always painful

[olsen]

Here i from the 3.1 update on aminet (http://aminet.net/package/comm/net/Envoy3_1Update)

(It is also worth nothing that this update has binary patch for a2065.device and ariadne_ii.device - hm, why is that)

Because there were bugs in each which both could and should be fixed?   The a2065.device is not exactly notorious for being full of surprises, but it should be. In the Roadshow bsdsocket.library I had to work around a2065.device bugs which were easily triggered. Even the original AmiTCP 3.0b2 code featured a workaround which passed the respective I/O request unit pointer in register A3 when calling AbortIO(). And unless S2_DEVICEQUERY features Sana2DeviceQuery.SizeAvailable = offsetof(struct Sana2DeviceQuery, RawMTU), some a2065.device versions (there are at least three which I know of) will crash instantly.

[olsen]

@olsen

Thank you for taking time to answer this, it’s a bit puzzling with these commands in OS 3.2 that don’t appear to do anything,  it’s not obvious they are only for network filesystems, in practice only Envoy.

Indeed, the expected file system behaviour is specific to Envoy's "EnvoyFileSystem" (mounts the shared network volumes) and its counterpart "filesystem.service" (enables a directory or volume to be shared and mounted).

And back in the days, also MuFS (which integrated better with IP stacks, as uid/gid 0 is “root/admin” and not “nobody/guest”).

With Envoy's "filesystem.service", both the user ID and the group ID value 0 refer to the Administrator. By default, this will deny access to all the directories, files, etc. exported by the volume. You have to deliberately add the users and groups who/which should be able to access the contents of the volume and then make use of the Owner and Group shell commands to grant them access to the specific directories and files which should be available. Which is a sound approach, I would say. This is not a "toy", it has a sensible technical foundation.

Do you know of any other filesystem supporting this? Your own smbfs perhaps? I don’t see any attempt to open any library or resource when using owner/group/list…

I am not that well-read when it comes to file systems and neworked file systems in particular   From what I gather, the approach taken by filesystem.service and EnvoyFileSystem emerges directly from the concepts which underpin Envoy: simplicity and usability vs. requiring the user to set up every little thing correctly and getting slapped in the face if just one of these things is not entirely correct. SMBv1/CIFS features administrative level management commands which are sent by the client to the server, which are comparable to the filesystem.service/EnvoyFileSystem message set (changing/querying authorization rights, ACLs, etc.), but on a far larger scale. They also work only within the SMB "ecosystem", e.g. Windows NT and beyond (the official CIFS documentation does not go into any kind of detail for these messages). My smbfs port is definitely a client which relies upon the server to grant it access to the resources it is entitled to. It has no business even trying to provide administrative access methods.

As for bugs in sana2 devices, yes… that’s always a problem, not all sana2 devices were “prepared” to be shared.

Not all SANA-II devices were doing the boring parts of the job to begin with. Namely, validating the OpenDevice() parameters, the I/O requests submitted to Begin() and AbortIO(), and dealing gracefully with wonky input, returning a helpful error code. The whole point of using exec devices is in being able to validate and reject invalid input in real time. If you cannot even accomplish that, why even bother? 

[olsen]

here's a relevant follow up I'd love to hear an answer from @olsen about

Both Inet225 and Envoy offer service discovery and control mechanisms for 'daemons' effectively. Also, RexxMast could be considered to be a 'daemon' in the unix sense. While AddDataTypes could be considered to be a kind of registry for plugins.

Modern platforms obviously have systemctl, launchd etc for this kind of thing. What would a system wide service discovery and management solution for amiga OS look like?

Hm... I have worked with INet-225 when it became part of the Amiga-Surfer product for Amiga Technologies GmbH, but I did not explore the technical aspects which distinguished it, compared to AmiTCP (at the time the only contender). INet-225 did support inetd-style daemon services, but so did AmiTCP. It was baked into the BSD TCP/IP "stack". Envoy made use of local UDP broadcast, for peers to announce their presence. Not exactly what would be called service discovery these days, which would be Zero configuration networking (Zeroconf) which makes use of multicast DNS.

RexxMast certainly qualifies as a daemon in the same vein as the inetd-style daemon services offered by TCP/IP stacks. Except that this is a local service which does not support network operations or discovery. It could have been interesting to make an Envoy service that would have allowed for remote ARexx script execution. Envoy's networking model was designed as an extension of the exec FindPort/PutMsg/WaitPort/ReplyMsg message passing.

The DataTypes system is something else, in my opinion. Its focus is on representing on-disk data via BOOPSI objects, with datatypes.library finding the relevant disk-loaded classes to match the file contents. You may ask for DataTypes to produce an object for you, but you may not get it.

We don't really have a general service discovery mechanism in the Amiga operating system...

[olsen]

According to the SANA-II standard, stacks should be able to share received frames:
(https://wiki.amigaos.net/wiki/Revision_2_%2B_3#Buffer_Management)

Indeed, but in practice Envoy steals every single frame it receives before a TCP/IP stack or other consumer (Oxxi Novell Netware client, etc.) could claim it. I used to suspect that this was a limitation of the respective SANA-II drivers I saw this behaviour with, but it is a feature of the filter to say to the driver that the frame was intended for it, thank you very much, even if this turned out not to be the case. This likely was a bug in the Envoy implementation and is, as far as I know, still present in Envoy 3.x. The Envoy filter should never ever consume broadcast ARP frames and it should never consume IP frames with unicast UDP traffic unless intended for port 376. Yet it does

I know this is only a recommendation, but it seems it should allow Envoy and a TCP stack to coexist, at least when using certain drivers, such as the A2065 one mentioned above and several of my own.

My theory is that the code was not tested as thoroughly as it should have been and the handling of the SANA-II filter by Envoy slipped by undetected. It may have been tested only within an isolated network which was used by the Amiga Networking Group.

[olsen]

But I don't see anything in the SANA-II docs to say that a driver shouldn't also offer a frame to other stacks if one stack's filter hook accepts the frame. So to me it seems more like a bug in the driver if Envoy interferes with another stack in this way, as it might be a valid case for multiple stacks to be interested in the same frame, and my interpretation of the docs is that a TRUE result from a stack's filter hook just means "yes, I'll take a copy of that", not "hands off, it's mine"

Except that the documentation does not go into detail how you should implement the filter on the driver's side. There exists exactly one officlal Commodore implementation of the "S2_PacketFilter" feature in the internal "slip.device", which features the version string "slip 38.1 (17.2.94)".

Correction, half an hour later: I reread the implementation's code and realized that I was looking at the wrong thing.

So, let's start over again how "slip.device" deals with the "S2_PacketFilter" feature.

When a new frame arrives, "slip.device" will offer a preview of the frame to every client which currently has a CMD_READ pending. If the client's hook code likes what it sees and returns a non-zero value, then the CMD_READ request's CopyToBuffer() callback will transfer a copy of the frame to the client and the CMD_READ command will be "terminated" by removing it from the queue, calling ReplyMsg() if the IOF_QUICK flag is not set. If the hook code returns zero, then the client will not receive a copy of the frame. "slip.device" walks through the list of clients which submitted CMD_READ commands until it has reached the end.

This means that every client gets asked if it wants to process the frame or not. Nobody can steal a frame. Every client receives a copy if it wants to.

If this is how it should work, it raises the question if every SANA-II driver out there that supports the "S2_PacketFilter" feature implements it correctly.

The Envoy 3.0 filter hook might just be a "victim" of SANA-II drivers not implementing the filter feature consistently.

[olsen]

I'd put money on it However, cnet.device seems to do it properly (to take another random example that has source code available).

I checked and both ariadne.device and ariadne_ii.device do the right thing, too   Wish I could have said that for ppp-serial.device and ppp-ethernet.device, but I had last updated these in 2017 (time flies) and did not know any better at the time. "Luckily", ppp-serial.device and ppp-ethernet.device are typically "single client only".