TCP/IP bounty beta release

Stat – I saw that when rummaging around the header files myself looking to answer that. Well, we don’t have inodes and we don’t have user IDs and what exactly is “last modified” with a socket stream?

This sounds to me like some rubbish thought up by an operating system that treats streams as files and files as streams, and I struggle to understand the relevance (or point) of that information in the context of RISC OS.

Would it not be much more logical to have a structure with more useful information (“is (not) connected”, “type of encryption”, “last SSL error”, etc) instead?

It’s great news to see no significant issues have come to light so far, but that doesn’t stop us – we have a new version of the beta available here. Changes in v2 include:

• Fix “buffer too short” error from Toolbox Res icon
• Don’t close the client’s socket if the client used CreateSession SWI
• Minor corrections to docs
• Ioctl SWI now does something, added hints on non blocking connections to docs
• Fix uninitialised pointer error if Creat SWI didn’t complete
• Fix to Version SWI returning the number 100 times too large
• Add Send to counter Recv, and Read to counter Write

Edit: didn’t see the messages after Colin’s when I wrote this, so this response looks odd…

Thanks. PRM5a has eluded me so far.

In the meantime, I’ve done some more testing with AntiSpam. Although a ‘full’ session works fine, starting a session on a previously created socket (e.g. when you issue an STLS command after a CAPA) fails as soon as you start writing. I would have expected an ENOTCONN until the handshake was completed, but instead I get:

Handshake error (state 28,928)

with an error number of &813F27.

Quite possible that’s because I’m doing something I shouldn’t be doing, but what?
Can AcornSSL_CreateSession only be used on a freshly created socket which isn’t connected yet? In that case the module is of limited use for POP3 sessions.

OK. Hold that. I’ll have a go with the new version.

Handshake error

I got that too. Figured I was doing something wrong, so just reverted to using a blocking connection where AcornSSL handles it all.

In that case the module is of limited use for POP3 sessions.

Yeah… isn’t it STARTTLS or something, where the sign in is in plain text (as usual) and then it switches to SSL afterwards?
I never quite understood the point of that – why encrypt messages when the login is not encrypted? My friend agreed, his mail server (that I use for my private address) runs the entire session as encrypted.

What exactly is AcornSSL_Recv supposed to return when blocking and when EWOULDBLOCK is to be returned?

I’m getting the SWI fail (X form) returning a pointer to an error block that makes no sense:

ssl_recv error reply is &20002024

I have inserted some code to do a *Memory command and spit it to file. The result…

Address  :     7 6 5 4     B A 9 8     F E D C     3 2 1 0     7 6 5 4     B A 9 8     F E D C     3 2 1 0 :            ASCII Data
20002024 :    000001E6    20495753    31303826    6E203634    6B20746F    6E776F6E    2D002900    20002931 : æ...SWI &80146 not known.).-1).

This happens repeatedly.

BTW – it’s not because I don’t have AcornSSL loaded – Manga checks for that and the AcornSSL_Recv SWI is &70F87 (X form).

Only the greeting and the CAPA (capabilities) command are in plain text when you use the STLS method. The rest is encrypted, so no plain text login.
The only advantage I can see is that you use the same port as for unencrypted connections (110), so you don’t have to listen on two ports (110 and 995).

New version still fails, unfortunately. Same error as before.

For what it’s worth, the code I’m using is this:

int  ssl_recv(int s, char *msg, int len, int flags)
{
   int  reply = 0;
   os_error *error = NULL;
#ifdef ASSLBUG
   char somemem[128];
#endif

   __asm
   {
      MOV   R0, s
      MOV   R1, msg
      MOV   R2, len
      MOV   R3, flags
      SWI   XAcornSSL_Recv, {R0-R3}, {R0, PSR}, {LR}
      MOV   reply, R0
      MOVVS error, R0
   }

   if (error != NULL)
   {
#ifdef ASSLBUG
      debug("ssl_recv error reply is &%08X\n", error);
      sprintf(somemem, "Memory %08X +20 { > $._asslerr }", error);
      __asm
      {
         MOV   R0, somemem
         SWI   5, {R0}, {}, {PSR, LR} // OS_CLI
      }
#endif
      if ( (error->errnum >= 0x20E00) && (error->errnum < 0x20E80) )
      {
         errno = (error->errnum & 0x7F);
         return -1;
      }
      else
      {
         errno = error->errnum;
         return -1;
      }
   }

   return reply;
}

It’s some inline assembler to veneer the SSL SWIs to the same functions as provided by SocketLib, only with “ssl_” prefixed.

The debug() function is like printf to DADebug. So if the SWI returns an error, its address will be passed to DADebug, and immediately (to prevent it being overwritten), the error block will be dumped to file.

A quick look at the AcornSSL module in Zap gives no clues as to what is happening here. And since this SWI is unknown to my system, it isn’t as if I can say “Oh yeah, I wasn’t running blahblah”.
(just had a quick look, it’s not Reporter either ;-) )

ssl_recv error reply is &20002024

Hang on – isn’t that just error &24, 36 decimal, EINPROGRESS?

with an error number of &813F27

- and isn’t that error &27, 39 decimal, EDESTADDRREQ?

I could of course be wrong.

If so, they’re “packed” in a peculiar way. And isn’t EDESTADDRREQ supposed to be about connectionless protocols (UDP)?

Hang on – isn’t that just error &24, 36 decimal, EINPROGRESS?

God knows, but probably not as it is an address that points to a valid error block in the RMA. The “error reply” is physically what was in R0 on exit (not an error number or anything) which, being assigned on a VS condition following a SWI call, ought to be an error block.

The reason I say “God knows” is because the example program provides a method of determining the internet stack return codes via a set of specific error numbers, while the documentation doesn’t actually mention how these errno codes are returned. So I’m assuming the example is correct and that it should be returning something like &20E24 (or whatever, I’m in bed not at the computer) to specify an EINPROGRESS state.

If so, they’re “packed” in a peculiar way.

I’m going to wait for some clarification as to what exactly is returned in the case of a reportable error. It could just as equally be -35, for instance, because you won’t get a negative number of bytes to read so state could be denoted in that manner. I don’t think it does, but I’ll await a reply on this point (I noted earlier that the http example doesn’t do non blocking ☺ ).

If would be nice if there was info on how the http/s works with the Wimp – ie best practice.

(would like to be able to download – Morse code)

Is there going to be converter prog for between SecureSockets and AcornSSL.

Any thoughts of adding ‘EasySockets’ functions to the AcornSSL module?

After going through the AcornSSL doc again, I get the impression the current incarnation of the module simply isn’t capable of handling the SMTP StartTLS / POP3 STLS switch (which happens on an already connected socket).

@Steve Revill
Could you please confirm/deny this?

If it is capable, what’s up with the ‘Handshake error (state 28,928)’?

After going through the AcornSSL doc again, I get the impression the current incarnation of the module simply isn’t capable of handling the SMTP StartTLS / POP3 STLS switch (which happens on an already connected socket).

Based on the entirety of what I know about StartTLS I can’t see how you’ve arrived at that conclusion having read the docs. Could you explain a little more what you’ve tried? I’d expect something along the lines of:

• Get a normal socket with Socket_Creat
• Then Socket_Connect to port 25
• Do the plain text bit
• Create an SSL context with AcornSSL_CreateSession to handover the socket you got
• Do an AcornSSL_Connect (probably, you’re already connected, but the examples provided all do this)
• Read or write, expecting ENOTCONN during the handshaking process
• Do the secure transfer bit

Untested of course, can you list the sequence you normally use?

I’m getting the SWI fail (X form) returning a pointer to an error block that makes no sense […] SWI &80146 not known […] A quick look at the AcornSSL module in Zap gives no clues as to what is happening here. And since this SWI is unknown to my system, it isn’t as if I can say “Oh yeah, I wasn’t running blahblah”, it’s not Reporter either.

If only there was a big list of allocated SWIs to consult. Oh wait, there is, it’s PDriver. I find it unlikely that AcornSSL tries to interact with PDriver and much more likely that by the time the error message buffer was printed it had been recycled by MessageTrans.

Also

errno = error→errnum;

Was there a part II to the article on IconBar about programming – using the Internet sockets?
(By Lee Johnston)

I now have HTTPS up and running in my (yet to be released) app. Unfortunately I’ve run into a problem that Jeffrey alluded to last week: My app calls a URL on a timer, but it’s a self-signed certificate and therefore the confirmation window pops up, and therefore the request isn’t made at the correct time (or at all, if you’re away from the machine).

If some sort of override could be added then I’d appreciate it.

I find it unlikely that AcornSSL tries to interact with PDriver

AbortJob? Just a guess, as there’s nothing else even remotely likely to be of significance (and it’s not AcornSSL’s job anyway).

and much more likely that by the time the error message buffer was printed it had been recycled by MessageTrans.

In that case I give up. If the error block can be corrupted between the SWI call and the scant few instructions prior to sprintf, there’s no hope of working out what’s going wrong.

Also errno = error→errnum; doesn’t make much sense, because RISC OS error numbers are in a different number space to C’s errno

Exactly. But the mechanism for reporting the errors doesn’t permit one to return an error code when -1 is all that is expected. Still a moot point though, as we’re not even getting far enough to need to wonder what to return to the caller. The SWI itself is returning something weird.

Maybe you translated the BASIC example a bit too literally? Try looking at socklib for inspiration – BASIC doesn’t have errno.

Looks like that code is doing the same thing. If in the DCI4 range, convert it to a simple value in errno (&0-&7F or somesuch), otherwise store the error number as is.

I repeat my request – please can the docs specify exactly how errors are returned, and what the read call is supposed to return in the case of EWOULDBLOCK. Better yet, it would be good if the example picked up the SSL after a normal connection (example for Frank) and did a non blocking fetch.

Fetching stuff works fine in blocking mode. Switch to non blocking, the result is… unexpected. As described above.

Do an AcornSSL_Connect

That’s the bit that was missing. Thanks.

(probably, you’re already connected, but the examples provided all do this)

Examples? With CreateSession? You must have access to other examples then, because the examples that came with the beta zips don’t have any reference to Connect w.r.t. CreateSession.

Edit
Actually, the AcornSSL_Connect call exits immediately with EISCONN which is slightly confusing if you don’t expect that. Just ignore it and start the ENOTCONN loop until that clears.

and much more likely that by the time the error message buffer was printed it had been recycled by MessageTrans.

In that case I give up. If the error block can be corrupted between the SWI call and the scant few instructions prior to sprintf, there’s no hope of working out what’s going wrong.

sprintf is irrelevant. In the code you’ve posted, it’s the implementation of the *Memory command which will read from the error block, and there’s an untold number of instructions between your code detecting the error and Debugger’s *Memory handler being entered (the DADebug SWIs within debug() could trigger callbacks, OS_CLI will do things, the filesystem will do things to open up the file you’re redirecting the output to, etc.)

One of the only reliable ways of dealing with errors within usermode code is to make a copy of the error block (or at least the error number) before you make your next SWI call. This would necessitate storing the block on the stack or in some pre-allocated area of memory – you can’t use malloc because that could require a SWI call to extend the wimp slot.

Note that _swix, _kernel_swi, and friends will make a copy of the last error block within the workspace of your app/module (available via _kernel_last_oserror) – but that’s still very weak protection against the value being overwritten, compared to manually making copies when needed.

Hi all, I’m currently working on some code that does a secure exchange of data with a SOAP server. Until now, I’ve used the SecureSockets module, but today it started failing (after they did a security update on the SOAP server). I then decided to convert my code to using the AcornSSL module. My code is written in assembler (module), and I’m using the Beta test version of Acorn SSL. Let me start by saying that I’m really happy with the update of AcornSSL.

I can successfully do a SWI XAcornSSL_Creat, followed by SWI XAcornSSL_Connect.
The problem starts as soon as I try to write data to the handle, using SWI XAcornSSL_Write.
I first get INET error (57) ENOTCONN. I then do a retry, an get the same INET error (57) ENOTCONN.
I then do a retry, and get an error outside INET: 8470311 handshake error (state 80).
If I ignore this error and try again, I get the same error number, with a different description: 8470311 handshake error (state 29,312).
I believe these errors are in the same realm as the one report by Frank de Bruijn.

After inserting SWI XAcornSSL_SetSessionHost to associate the connection with a hostname, I suddenly get a different error behaviour. On some occasions I’m now able to write data and get a reply from the server (with no errors other than 57), but more often than not, it returns with the odd error 8470311 Handshake error (state 76). To me, there seems to be an error in reporting back the current state of the connection.

Another problem which might help to solve the above one:
After several attempts to connect (quite a few) it seems to use up all the available module space. Trying to save my own module then results on the OS error The area reserved for relocatable modules is full. To me this indicates that there might be a memory leak somewhere.

Any help would be much appreciated.

Interesting. I was just about to report I’m also seeing the “Handshake error (state 80)” on some connections. Here, the usual ENOTCONN sequence sometimes runs into a useable connection but more often stops at “state 80”. I was wondering whether this had anything to do with hostname association and your experience seems to confirm that. Now I’m wondering what the “state 76” error means…

To the AcornSSL developers: a bit more info about these “state errors” would be helpful!

And yes, the module area here is considerably larger than usual (not full yet, but getting there).

Actually, using SetSessionHost doesn’t make any difference here. The same handshake error occurs for the same hosts.

Another error that keeps popping up during an XAcornSSL_Read call is 8470310 Socket error (code 76) . Same error when using XAcornSSL_Recv.
When I ignore this error, the requested data will be read. This indicates that the data is available, but that somehow the wrong error is generated (if an error should be generated at all).
Is it possible that the V-flag gets erroneously set?

I am also observing that, when it works, it is incredibly slow compared to the old SecureSockets. This might indicate a loop hole somewhere.

it is incredibly slow compared to the old SecureSockets.

That’s because the level of encryption offered by SecureSockets is much less challenging – computationally easier. There may be some optimisations possible, I’d imagine the work is concentrating on first making the module good and stable.

I also saw the “Socket error (code 76)” after I had added a Connect after CreateSession. I had forgotten to change some code elsewhere and was trying to read something that wasn’t there (needed to send a POP3 USER command first). I haven’t seen that particular error since I fixed that. So maybe this error is a kind of EWOULDBLOCK. I don’t know what the actual code is supposed to mean – if it is a ‘real’ socket error at all.