Envoy source and availability

[ncafferkey]

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.

According to the SANA-II standard, stacks should be able to share received frames:

Another recommendation for the ``magic cookie`` is to use it to maintain a separate packet read queue for each device opener. This would allow multiple protocol stacks that all wish to receive the same packet type to work together without having to "know" about each other as Envoy and AS225 do right now. What does multiple protocol stack support mean? Basically this means that each opener gets all the packets necessary. If a packet comes in that fills a request for more than one opener of the device, all of them will get a copy of the packet. This feature should never be left out of a device design. If it is missing, the usefulness of the device is severely limited.

The SLIP and A2065 driver now do this, so it would be possible (for example) to run Envoy, AS225 and the AmiTCP package together on the same hardware without conflicts.

(https://wiki.amigaos.net/wiki/Revision_2_%2B_3#Buffer_Management)

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.

[ncafferkey]

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"

It might be interesting to do a test with 3c589.device, Envoy and Roadshow to see if they get on well together, as I think they should.

[ncafferkey]

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

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