SANA-II files for development in SAS/C?

[Piru]

SANA2 drivers are used by the TCP/IP stack to send and receive packets. Very few other applications use SANA2 directly (Envoy comes to mind).

[Piru]

Yes, this would be the exact thing I'm trying to achieve.

What exactly are you trying to achieve?

Is SANA included with Kickstart 3.1?

No. SANA2 are device drivers located in DEVS:Networks. Kickstart is ROM only. Workbench 3.1 doesn't include any network drivers either. Typically these drivers were provided by the HW manufacturer. Later on drivers were provided for common PCMCIA network cards, for instance.

In the documentation I only see references to header files, structs and functions. What library provides these functions? Or am I completely missing the mark here?

No library provides any functions.  The device drivers do provide the S2 commands.

[Piru]

I would like to write a software stack that interfaces with my SANA compliant network

Why? Why can't you use IP?

I should also warn you that very old device drivers do not handle multiple readers correctly. Only the SANA2 R2 and later demand that packets are sent to all readers. If this is not implemented correctly the result is that packets appear to be lost (when they are read by the "other" caller).

This means that you won't be able to use the driver reliably for two different things.. such as TCP/IP Stack and Envoy. Luckily such buggy drivers are in the minority these days.

If I understand correctly now, the device driver for the NIC "extends" the system with SANA compliant functions - correct?

No. The drivers are standalone drivers, they don't integrate to the system other than being opened with OpenDevice() call, just like any other device driver.

How would this work with multiple NICs present in the system?

You open the correct device and unit number for your NIC.

Does the device spec include some sort of unit numbering, where each unit corresponds to a unique set of SANA functions?

No.

If SANA functions are provided by the network card device driver (eg. a2065.device or ariadne_ii.device) then the implementation of that device driver is according to SANA spec version - is there some way to check to which spec the driver conforms?

Not by design, but it should be possible to detect it manually.
If device implements S2_ADDMULTICASTADDRESSES then it's R3.

If device implements commands from http://web.archive.org/web/20020602075950/www.amigadev.net/documents/sana2r4.html then it's R4.

However, it isn't that clear cut. There are other extensions as well, and some drivers might have gaps in their support. That is they might support some extensions while ignoring some other.

[Piru]

I do not want to use an IP stack, as I want to code a small traffic generator - thus building my own packets...

Well, if you bypass the IP stack you're going to have to implement quite a bit of stuff, for instance ARP daemon. Unless of course if you're going to send the packets to MAC address rather than IP address...

[Piru]

Careful with the ARP packets: due to how many, if not most SANA-II drivers work, multiple clients trying to read incoming packets will interfere with one another. Typically, the first client which manages to receive a packet it asked for will prevent that packet from reaching all other readers.

This not not how it is supposed to happen. A SANA-II driver must offer the same packet to all readers and must not assume that if the first client accepts it the packet has been dealt with.

Note that this issue is not limited to ARP packets. IP packets may get "lost" in the same manner.

Sure, but as already mentioned anything SANA2 R2 compliant must support multiple readers. All my drivers do at least.

[Piru]

It would be nice if all SANA-II R2 compliant drivers actually worked correctly, but you can only hope. For example, "a2065.device", last updated by Commodore in around 1993/1994, will make the first reader of a packet "consume" that packet, denying other readers access to it. It's possible that other drivers of the same age do the same (I haven't checked "ariadne.device", but it might have this "bug", too).

They're not R2 compliant then. I know that even the SANA2 example code has this bug. Anyhoo, I'd still argue that most new drivers handle this correctly.

There are more problems than this multireader issue however, in many cases things will go wrong anyway. For instance if you try to perform TCP traffic with two readers, if the "wrong" reader gets a SYN|ACK the reader will RST the connection.

[Piru]

Interesting point. I think that it may not be quite so risky that a connection will drop. The greater risk may be in that a three-way handshake during connection establishment and tear-down may get derailed.

It takes an effort to tear down a connection, especially by mistake. Accidentally kicking a three-way handshake on the shin, so to speak, might be more easily triggered.

Usually when such trickery is done, the real TCP/IP -stack is prevented from seing the extra traffic by dynamically setting up a temporary firewall rule. This is what I did in my suckstress tool, for instance.