Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: mousehouse on September 07, 2010, 11:07:03 AM
-
After installing SAS/C 6.58 from my still functional original floppies I went looking for the SANA-2 files needed for writing some C code... On my installed system it is not present (thus not included in SAS/C), I found the following using Google,
http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node01DE.html
This seems to be an online version of the Amiga Developer CD 2.1. Can somebody comment if these are the latest header files available for SANA-II development?
-
These (http://aminet.net/package/dev/misc/sana2_v2) are more up to date.
-
Thanks! On Aminet of all places ;-)
Does anybody know if the sources for sanamon or similar have ever been released? I'm looking for some understandable sample code...
-
I don't know about Sanamon, but the sources for SanaUtil are available. The are sources for some drivers available too if you're interested in implementing a SANA-II device.
BTW, those includes on Aminet don't include the additions to the standard made in subsequent years.
-
I don't know about Sanamon, but the sources for SanaUtil are available. The are sources for some drivers available too if you're interested in implementing a SANA-II device.
BTW, those includes on Aminet don't include the additions to the standard made in subsequent years.
Oh, that's right, I think the package I linked was SANA-II R2. I remember some documentation about a semi-official SANA-II R3 and maybe R4. Did Olaf Barthel work on those? Or was it someone else?
-
Multicast address range extensions to SANA-II Rev 3 (http://web.archive.org/web/20030507084025/http://www.nordicglobal.com/sana2mc.txt), Extending the SANA-II network driver specification SANA-II R4 (http://web.archive.org/web/20020602075950/www.amigadev.net/documents/sana2r4.html) & Hook-based callback function extensions for SANA-II (SANA-II R5) (http://web.archive.org/web/20040622182835/www.amigadev.net/documents/sana2r5.html).
-
Thanks for those excellent resources.
One thing that puzzles me (because of a lack of understanding - I have never done anything with the networking- or kernel part of AmigaOS and as far as programming goes, I am only an average C programmer with dated skills) is the functionality provided by the SANA layer.
Am I correct in understanding that SANA provides an abstraction layer between the hardware (NICs or software interfaces) and possible software that use it?
If so, I need to be able to address SANA supplied functions and procedures to make the abstracted hardware do as I wish ;-) I've actually read the complete spec but the wisdom doesn't come to me yet...
-
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).
-
Multicast address range extensions to SANA-II Rev 3 (http://web.archive.org/web/20030507084025/http://www.nordicglobal.com/sana2mc.txt), Extending the SANA-II network driver specification SANA-II R4 (http://web.archive.org/web/20020602075950/www.amigadev.net/documents/sana2r4.html) & Hook-based callback function extensions for SANA-II (SANA-II R5) (http://web.archive.org/web/20040622182835/www.amigadev.net/documents/sana2r5.html).
Did these go past proposal and discussion to be ratified into the spec?
-
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).
Yes, this would be the exact thing I'm trying to achieve.
Thus, in order to be able to address the networking hardware in my Amiga (it being anything supported by a SANA compliant driver) I need to talk "SANA"...
Is SANA included with Kickstart 3.1? 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?
-
Did these go past proposal and discussion to be ratified into the spec?
Don't know how that would work these days, R3 was included on H&P's Developer CD 2.1, but I'm not sure who was involved with that besides Heinz Wrobel. Seems the few people implementing stacks and drivers have extended the spec as needed.
-
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.
-
Did these go past proposal and discussion to be ratified into the spec?
That implies some sort of ratification process. I think they can be considered official as of OS4; however, any device driver writer is free to implement newer features.
-
Did these go past proposal and discussion to be ratified into the spec?
They represent the current state of the technology. It's not as if we had a board of officers charged with reviewing and casting proposals into a common specification. With SANA-II it's more like a cheap version of the RFC approval process: you work on your proposal, talk it over with your peers, and then you publish it. The documentation should be good enough to write code for it, and to leave no obvious questions unanswered. Better still, publish example code for your proposal.
-
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?
-
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.
-
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...
-
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...
-
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...
-
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.
-
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 (http://www.amiga.org/forums/showpost.php?p=578443&postcount=16) anything SANA2 R2 compliant must support multiple readers. All my drivers do at least.
-
Sure, but as already mentioned (http://www.amiga.org/forums/showpost.php?p=578443&postcount=16) 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).
-
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.
-
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 ;-))
-
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.
-
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 (http://sintonen.fi/video/misc/suckstress.avi), for instance.