SANA-II files for development in SAS/C?

[mousehouse]

What exactly are you tring to achieve?

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.

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

I would like to write a software stack that interfaces with my SANA compliant network card (A2065, Ariadne2, USB thingie of Deneb).

If I understand correctly now, the device driver for the NIC "extends" the system with SANA compliant functions - correct? How would this work with multiple NICs present in the system? Does the device spec include some sort of unit numbering, where each unit corresponds to a unique set of SANA functions?

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?

[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.

[mousehouse]

Thanks for the excellent help on this, I'm only just starting to grasp the first basics of this. I do not want to use an IP stack, as I want to code a small traffic generator - thus building my own packets...

I'll try to find some understandable sample code on Aminet...

[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...

[mousehouse]

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...

First attempt will be something easy, just to get it up and running. For that I can use a static MAC-IP table... Just found 'sanautil' om Aminet... very nice little program, documented and readable sourcecode thanks to Timo Rossi.

I think I will try to compile/build that first and then go from there...

[olsen]

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...

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.

[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.

[olsen]

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

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).

[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.

[mousehouse]

This means my little project will be a lot of fun! Of course, I could do it on any other platform - but I'll just love doing it on my A4000!

(Please remind me gently of this post when later on I'll post rants about illogical / badly written / buggy stuff that I'll be forced to use ;-))

[olsen]

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.

I would hope so, but the number of reference driver implementations is so low that the poor example of the slip/cslip driver in the SANA-II SDK of old is bound to lead developers to implement the same bugs in their code. I know that I did in my ppp-serial.device and ppp-ethernet.device drivers, and it took me a while to notice that I was doing something wrong.

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.

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.

[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.