All, is there an up to date set of SANA-II specs available? The SDK includes the headers, of course, but the related documentation is conspicuously missing. Was R5 the last revision? Should I be sifting through Roadshow-related information for SANA-II nuggets?

In general, any device development information for OS4 would be useful. The lack of drivers for third-party hardware isn't surprising given the lack of documentation for developing said drivers.

Trev

Last edited by Trev on 08-Feb-2008 at 02:42 AM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev
I think you'll have better luck at www.utilitybase.com

_________________
ExecSG Team Lead

@Trev

download the old SDK from aminet, just remember that the 680x0 data and address registers are emulated on os4.

#include <exec/emulation.h&rt;

int MemCopy( )
{
ULONG *regs;
uint32 len;
uint8 *to, *from;
int i=0;

regs = (ULONG *)(((struct ExecBase *)SysBase)->EmuWS);

len = regs[REG68K_D0/ 4];
to = (uint8 *) regs[REG68K_A0/ 4];
from = (uint8 *) regs[REG68K_A1/ 4];

for (i=0; i<len; i++) {
to[i] = from[i];
}

regs[REG68K_D0/ 4] = 1;
return 1;
}

Last edited by NutsAboutAmiga on 08-Feb-2008 at 06:41 AM.
Last edited by NutsAboutAmiga on 08-Feb-2008 at 06:41 AM.
Last edited by NutsAboutAmiga on 08-Feb-2008 at 06:39 AM.
Last edited by NutsAboutAmiga on 08-Feb-2008 at 06:37 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@ssolie

That depends,

I don't go to utilitybase, because do not need help.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@ssolie

Thanks. I've posted a query over at UtilityBase.

@NutsAboutAmiga

The S2 stuff on H&P's Developer CD 2.1 is newer than what's on Aminet. I'm actually more interested in the changes Olaf Barthel put in over the last few years and documentation regarding the less commonly used buffer management tags. Thanks for the sample copy function, though. Is no one writing native OS4 devices?

Trev

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

The S2 stuff on H&P's Developer CD 2.1 is newer than what's on Aminet. I'm actually more interested in the changes Olaf Barthel put in over the last few years and documentation regarding the less commonly used buffer management tags. Thanks for the sample copy function, though

Well because of lack information on the subjected, I experimented and found out it was working better that way.

Quote:

Is no one writing native OS4 devices?

I guess classic AmigaOS4 users might be interested in support for some hardware, on AmigaOne the support is not that bad,
I think developers are happy about what they have (100/1000 mbps Ethernet and Wlan drivers, drivers found on OS4Depot.net)

What we need is drivers for VPN or some thing, so we can use Amiga computer in network at work

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Trev

Welcome aboard... Or at least grats on your first post

Are you thinking about writing drivers for something specific ?

Last edited by Seer on 08-Feb-2008 at 04:18 PM.

_________________
~
Everything you say will be misquoted and used against you..
~

@all

Olaf Barthel was kind enough to supply me with the most recent SANA-II documentation, including his proposed extensions (R4/R5). I'm free to share everything if anyone is interested.

@NutsAboutAmiga

I'd keep an eye on the work being done by Andrea Palmaté (Origyn/OS4) and Robert Norris (Traveller/AROS) in the WebKit space. I'd love to see those projects spur further development in areas like Java, primarily for support of the Citrix ICA Client for Java. A look into VPN standards would be nice, too, although most large organizations use custom implementations of proprietary solutions and multi-factor authentication that may complicate things. Still, support for L2TP/IPsec or SSL VPNs wouldn't be a bad thing to have. I imagine SSL would be the simpler option--perhaps a port of OpenVPN.

@Seer

I spend most of my time on the classic-oriented boards (no PPC Amiga here), but I've been an active Amiga user since 1989, with a brief hiatus around the time Tomb Raider, Quake, and the 3Dfx Voodoo chipset were released.

I have a few projects in the works, among them a port of uIP for all Amigas. The lowest spec system I have is a stock A500 with Kickstart 1.3, so that's my baseline. Toni Wilen's work on the uaenet.device for WinUAE has allowed me to test on a variety of configurations, so it may just end up working everywhere. Part of the overall project, though, is a new SANA-II driver or three.

Trev

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

The sources for prism2.device are on Aminet. It can be built natively for OS4, as well as for other Amiga-like OSs.

@ncafferkey

Thanks, Neil. I'd forgotten. I looked at the latest prism2.device and cnet.device source when trying to sort out why some devices can S2_CONFIGINTERFACE before they S2_ONLINE and some can't. It came down to different interpretations of the specification, which isn't too clear on what commands can be sent when an interface is offline. Olaf attempted to clarify this somewhat, but as we know, his documentation wasn't generally available. Anyhow, if the config fails in code, I just bring the interface online and try again. Every SANA-II device I and others have tested so far, including prism2.device, works well with that logic.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @ncafferkey Thanks, Neil. I'd forgotten. I looked at the latest prism2.device and cnet.device source when trying to sort out why some devices can S2_CONFIGINTERFACE before they S2_ONLINE and some can't. It came down to different interpretations of the specification, which isn't too clear on what commands can be sent when an interface is offline. Olaf attempted to clarify this somewhat, but as we know, his documentation wasn't generally available. Anyhow, if the config fails in code, I just bring the interface online and try again. Every SANA-II device I and others have tested so far, including prism2.device, works well with that logic.

The manuscript I sent you is just a compilation of the SANA-II documentation which existed in 2002. It looks prettier in pdf form, but it's otherwise unchanged. This also goes for the S2_ONLINE command semantics.

The SANA-IIR4 proposal, which my own "Roadshow" TCP/IP stack and its PPP drivers implement, adds new commands for devices which have to do extra work before they can go online, such as negotiating link parameters, or performing an authentication process. This is the context in which S2_ONLINE/S2_OFFLINE may get a very specific meaning.

I hope I didn't mess up the documentation with regard to these two commands. Normally, the S2_ONLINE/S2_OFFLINE commands are only supposed to tell the networking driver to take control/relinquish control over its layer 1 device, which may either be some real hardware or a transmission link implemented in software.

@olsen

I don't think a consolidated R3.1 specification has been available in the past, unless you've distributed it previously, and I just couldn't find it.

What we've found is that some devices return S2ERR_OUTOFSERVICE or S2ERR_BAD_STATE if you send S2_CONFIGINTERFACE before S2_ONLINE. Your S2_ONLINE comments in relation to the new S2_CONNECT command in R4 clarified the function of S2_ONLINE in my opinion. Some stacks, e.g. Genesis, send S2_ONLINE before ever having sent S2_CONFIGINTERFACE, and some devices expect and require this behavior explicitly.

From a device consumer perspective, I do something like this after having sent S2_DEVICEQUERY and S2_GETSTATIONADDRESS:


/* use address from S2_GETSTATIONADDRESS, if available */
CopyMem(request->ios2_DstAddr, request->ios2_SrcAddr, SANA2_MAX_ADDR_BYTES);

/* configure SANA-II ethernet device; in theory, this can only be done once */
request->ios2_Req.io_Command = S2_CONFIGINTERFACE;
DoIO((struct IORequest *)request);

if (request->ios2_Req.io_Error == S2ERR_OUTOFSERVICE ||
(request->ios2_Req.io_Error == S2ERR_BAD_STATE &&
request->ios2_WireError != S2WERR_IS_CONFIGURED)) {
/* this is a weird device that must be online before being configured */
request->ios2_Req.io_Command = S2_ONLINE;
DoIO((struct IORequest *)request);
request->ios2_Req.io_Command = S2_CONFIGINTERFACE;
DoIO((struct IORequest *)request);
}

if ((request->ios2_Req.io_Error != S2ERR_NO_ERROR) &&
(request->ios2_WireError != S2WERR_IS_CONFIGURED)) {
log("failed to configure SANA-II device: error %08lX",
request->ios2_Req.io_Error);
DeleteIORequest(request);
exit(RETURN_FAIL);
}


I believe this is similar to how Miami copes with the situation.

What's especially odd is the decision by some device developers to accept S2_DEVICEQUERY and S2_GETSTATIONADDRESS and not S2_CONFIGINTERFACE before S2_ONLINE. I think the R2 specification was unclear on the definition of "known state" used in the description of S2_ONLINE.

From a device perspective, one has to handle commands sent in any sequence, of course; however, special steps must be taken to properly support Genesis by allowing a successful S2_ONLINE request before S2_CONFIGINTERFACE, when a device should really be responding with S2WERR_NOT_CONFIGURED.

It's areas like these where the specification really needs clarification.

Last edited by Trev on 09-Feb-2008 at 05:46 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen I don't think a consolidated R3.1 specification has been available in the past, unless you've distributed it previously, and I just couldn't find it. What we've found is that some devices return S2ERR_OUTOFSERVICE or S2ERR_BAD_STATE if you send S2_CONFIGINTERFACE before S2_ONLINE. Your S2_ONLINE comments in relation to the new S2_CONNECT command in R4 clarified the function of S2_ONLINE in my opinion. Some stacks, e.g. Genesis, send S2_ONLINE before ever having sent S2_CONFIGINTERFACE, and some devices expect and require this behavior explicitly.

Hm... I never ran into any device driver which required the S2_ONLINE command to become operational, other than the slip.device/cslip.device, of course.

As far as I understand how the S2_ONLINE/S2_OFFLINE commands work, their purpose is for the user to tell the device to take his hands off the transmission medium. The device is supposed to take control of the medium when it is opened, and it should not require the S2_ONLINE command to become operational, unless it doesn't know how to do that.

For example, an Ethernet device driver is made for a particular kind of hardware, and "going online" means that it ought to take control of that hardware. The a2065.device, for example, could be told to go "offline", giving up control over the hardware, so that the LANCE test program could be run, which performed a test of the A2065 chip and memory.

The slip.device/cslip.device of old didn't know how to perform authentication or dial-up operations. You had to establish the SLIP connection "manually" before you could tell it to become active, which required the S2_ONLINE command.

Quote:

What's especially odd is the decision by some device developers to accept S2_DEVICEQUERY and S2_GETSTATIONADDRESS and not S2_CONFIGINTERFACE before S2_ONLINE. I think the R2 specification was unclear on the definition of "known state" used in the description of S2_ONLINE.

I rather suspect that the purpose of S2_ONLINE was not sufficiently clear. As I wrote above, there aren't many situations in which it can be considered as having any sort of useful purpose at all. And there's the fact that the kind of networking device SANA-II was written for is from the IEEE 801 family, and specifically Ethernet, which does not really have a distinct physical online/offline state that could be put under software control - you just plug in the connector to bring it online.

Quote:

From a device perspective, one has to handle commands sent in any sequence, of course; however, special steps must be taken to properly support Genesis by allowing a successful S2_ONLINE request before S2_CONFIGINTERFACE, when a device should really be responding with S2WERR_NOT_CONFIGURED. It's areas like these where the specification really needs clarification.

The original AmiTCP did not send or require S2_ONLINE commands to work. I daresay this would have interfered with the operation of the slip.device/cslip.device. I'd have to check the Envoy and AS225R2 source code, but I suspect neither sends S2_ONLINE commands either.

This is really the first time I read that network client software should be required to send S2_ONLINE commands.

@olsen

I don't have much time to respond right now, but I do want to chat some more about S2_ONLINE when I get a moment. In brief, we've seen startup issues with ariadne_ii.device, ioblixether.device, and norway.device. Per Michael Boehmer, sending S2_ONLINE before S2_CONFIGINTERFACE solved the issues for norway.device. I haven't had any recent feedback on the others.

It makes sense--to me, at least--that an Ethernet device would be logically offline until configured, as not all devices have a physical address in ROM, and some controllers may require initialization not performed until after a physical address is set. From a software standpoint, I've interpreted S2_ONLINE and S2_OFFLINE as commands to enable and disable, respectively, the processing of frames by the network controller. In user terms, S2_OFFLINE turns off the link light and logically disconnects the device from the media. That probably stems from my user experience with other operating systems, though, and not from any kind of low-level programming experience. (It may also be a bad assumption to make in other environments, e.g. token ring without fault detection.)

Back to Genesis: As shipped with OS 3.9, Genesis always sends S2_ONLINE as the first command. This confuses devices that fail S2_ONLINE until S2_CONFIGINTERFACE has been successfully received and processed. If the first call to OpenDevice should put the device in a online state, waiting for commands, then yes, the purpose of S2_ONLINE is not sufficiently clear.

More tomorrow....

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen I don't have much time to respond right now, but I do want to chat some more about S2_ONLINE when I get a moment. In brief, we've seen startup issues with ariadne_ii.device, ioblixether.device, and norway.device. Per Michael Boehmer, sending S2_ONLINE before S2_CONFIGINTERFACE solved the issues for norway.device. I haven't had any recent feedback on the others.

I checked the source code for ariadne.device and ariadne_ii.device. Both will complain with S2ERR_BAD_STATE for the S2_ONLINE command if they are already online. And being online is the default state for these devices, i.e. you open them, they're online.

Quote:

It makes sense--to me, at least--that an Ethernet device would be logically offline until configured, as not all devices have a physical address in ROM, and some controllers may require initialization not performed until after a physical address is set.

"online" does not mean "operational" with respect to how SANA-II considers the S2_ONLINE/S2_OFFLINE commands. I checked some of the Ethernet driver source code I have access to, and it's very common to initialize the hardware when the device is opened. By this time the transceiver hardware is usually operational, and some drivers even go so far as to initialize the station address to the hardware's default. S2_CONFIGINTERFACE then makes the device operational, e.g. it will begin to listen for packets intended for it.

Quote:

From a software standpoint, I've interpreted S2_ONLINE and S2_OFFLINE as commands to enable and disable, respectively, the processing of frames by the network controller.

That's part of the package, but not everything there is to it. For example, CMD_STOP has the same effect as S2_OFFLINE in that it causes the device to stop processing frames, yet you do not send a CMD_START command after opening the device.

Quote:

In user terms, S2_OFFLINE turns off the link light and logically disconnects the device from the media. That probably stems from my user experience with other operating systems, though, and not from any kind of low-level programming experience. (It may also be a bad assumption to make in other environments, e.g. token ring without fault detection.)

As far as the SANA-II documentation goes, S2_ONLINE is described as undoing what S2_OFFLINE did: "This command is responsible for putting the network interface hardware back into a known state (as close as possible to the state before S2_OFFLINE) and resets the unit global and special statistics.".

Since the driver's default state is, with exceptions for devices which cannot start in "online" state such as slip.device/cslip.device, "online" the documentation does not call for S2_ONLINE to be invoked at all times. S2_ONLINE is described as following S2_OFFLINE.

Quote:

Back to Genesis: As shipped with OS 3.9, Genesis always sends S2_ONLINE as the first command. This confuses devices that fail S2_ONLINE until S2_CONFIGINTERFACE has been successfully received and processed. If the first call to OpenDevice should put the device in a online state, waiting for commands, then yes, the purpose of S2_ONLINE is not sufficiently clear. More tomorrow....

As far as I can tell from the SANA-II documentation, the first command to send to a SANA-II device in order to make it operational is S2_CONFIGINTERFACE.

@olsen

Thanks for the clarification. From that, I'll assume (safely, I hope) the following:

1. The default state of a device is ONLINE.
2. S2_OFFLINE is used to release a device's control over the interface, after which the state of the device is unknown until S2_ONLINE is sent.
3. An offline device should return S2WERR_UNIT_OFFLINE for all commands that require the device to be ONLINE. (When would S2WERR_UNIT_ONLINE ever be used? I guess only as the result of an S2_ONLINE command sent while the device is ONLINE.)
4. An unconfigured device should return S2WERR_NOT_CONFIGURED for most commands until S2_CONFIGINTERFACE is sent.

I'm still not sure that all devices follow these semantics, but I'll hopefully pick up any descrepencies in testing, as I have done until now.

If a device configures itself during OpenDevice, e.g. by reading a stored physical address, what role does S2_CONFIGINTERFACE play? If a device must (or should) allow its physical address to be changed, can it only be changed by the first opener? We can't reliably track whether or not a user has stored the physical address for use in SANA2IOF_RAW requests, so it makes sense to only allow the user to change the physical address if they are the only active consumer of the device (and if the interface allows it, of course).

As you've noted then, the ONLINE and OFFLINE states of a SANA-II device relate specifically to the device's control over the interface. The internal state of the interface is not necessarily exposed by the state of the device driver.



Now for a new question. How do current Ethernet devices report link failures? Do we depend on events and S2EVENT_HARDWARE? Or do we hijack the ONLINE and OFFLINE states and act as if a user had sent S2_OFFLINE? Or do we just let higher-level reliable protocols manage errors in their own way, via ACK timeouts or other mechanisms?



And another: I'm not there yet, but have you thought about ways to implement IP checksum offloading for devices that support it? Granted, it would be the IP stack that makes use of the feature, but the stack would presumably make use of a SANA-II command--perhaps a new I/O flag--to tell the device what to do. It could be done independently of the SANA-II specification, but the stack would still need a way to know it's available. It might also confuse packet sniffers, as checksums would be incorrect for outgoing frames and may be incorrect for incoming frames.

(A bsdsocket.library wrapper for a TCP offload engine would be an interesting project, too.)

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

All, is there an up to date set of SANA-II specs available?

I think this is what I was (very poorly) trying to find info on from Wegster the other night in irc.

_________________
"The system no longer works " -- Young Anakin Skywalker