TCP/IP bounty beta release

Regarding handshake error, I don’t know if it helps anyone, but I saw that every time until I had the certificate bundle installed from nightly ROOL disc image. It goes in !Boot. Resources. !Internet.files

You guys probably have that installed already, but if not, I didn’t see it in a quick look through the beta zip. I’m probably being blind, but just in case it helps anyone, you need both the module and the certificates.

Hi Andrew, It is in the current Harddisc4 image and I do have it installed here. I assume the AcornSSL module has access to it.

The problem with the current errors is, that you won’t see them when using the demo program (with the hard-coded URL). However, I see it here when trying to access a seriously protected server with the latest security updates. I think the current release of the Acorn SSL module is nearly there, but needs ironing a couple of wrinkles. Like Frank, I see ‘incorrect’ error messages and a serious memory leak that potentially eats up the entire module space. I had to reset my machine at least three times this evening because of that that.

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

I was merely reading the examples (as provided) in the order they are written and repeating the steps in a list, since they worked. I don’t have magic access to some mythical CreateSession examples, though I can claim the dubious credit of having written the FTP(S) example – but I totally ripped off the HTTP(S) example to make that.

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.

From your point of view I’m not sure calling Connect a second time in the CreateSession case adds any clarity, since presumably you’re using the same address family/port/IP address before and after the StartTLS, right? If so I’d suggest dropping a line to ROOL (see the ReadMe) so that whatever side effects Connect has that makes it work for you could be done earlier in CreateSession and save yourself a SWI. That’d make more sense: Socket_Creat, Socket_Connect, AcornSSL_CreateSession, AcornSSL_Recv|Write.

For my own personal use, to reduce clutter in my app, I’ve made an “HTTPLib” where I just call httplib_get(url, callback); and it downloads the file and then calls the callback function (with the contents in a char * parameter). There’s also a function that I call right after event_poll which checks for any pending download and proceeds with it.

While this library needs a bit of work (e.g. it currently only supports GET and PUT, can only do one transfer at a time, doesn’t handle failure well, and is probably disastrous with larger files) I’m just wondering whether anyone else would find some use for it. If so, I can try to get it into a useful state over the next few days.

Still trying to work out how you would download Morse code – from a Morse site – MOIP instead of VOIP.
**************
For example, the packet for a V would look something like
(V= short short short long)
(dit dit dit dar)

(-2000, +50, -50, +50, -50, +50, -50, +150)

where each +50 represents a dot 50 ms in length, the +150 is the 150 ms dash, each -50 stands for an inter element space, and the -2000 means the V starts 2 seconds after the end of the previous character.

As another example, here’s the word TEST sent on a bug at about 25 wpm. Notice how each letter is sent in a separate packet, for a total of four packets.

(-347, +145)
(-183, +51)
(-160, +51, -47, +47, -51, +47)
(-211, +144)

As you might expect, the actual CWCom protocol is a bit more complicated than this.

Good news. With help from ROOL, I have managed to solve the ‘memory leak’ that was eating my RMA space. It was caused by the fact that I had made the socket non-blocking BEFORE doing a Connect, and then called it repeatedly until the connection was up. Changed to make the socket non-blocking AFTER the Connect (as described in ROOL’s doc) and the RMA is no longer eaten. Speed is now a lot better as well.

I can now connect to the remote server and write/read data, but it still bombs out occasionally with an OS error 8470311 during write, or OS error 8470310 during read. When I ignore these errors, it works as expected. We are nearly there ;-)

Ignoring the errors doesn’t work for me. There simply isn’t any traffic afterwards.

I have three of my test accounts working: one POP3S and two POP3+STLS. The others all end in Handshake error (state 80), whether I use SetSessionHost or not. It’s always the same ones that fail.
Did you get any info on what that state 80 error actually means?

My code also sets non-blocking right after creating the socket, but it never calls Connect more then once. I’ll check if moving the Ioctl call alone is enough the get rid of the memory leak.

Frank, as far as I can tell (from my limited experience), the only errors that can be ignored safely, are the ones that have the number 76 in the error message string, e.g.: ‘… (code 76)’ or ‘… (state 76)’. I have seen state error 80 during the early stages of my experiments, and I’m almost certain that it means that handshaking has failed, as a result of which you do not have a secure connection. After discussing error 76 with ROOL, I have decided to ignore them for now. ROOL has also confirmed that for servers that support SNI, you MUST call SetSessionHost with a pointer to the bare host name (e.g. ‘www.somewhere.com’) or else the server will disconnect.

I have the impression that the reported ‘state’ and ‘code’ errors are in fact NET errors. Looking in the mbed source (net_sockets.h), my code 76 (0×4C) might mean MBEDTLS_ERR_NET_RECV_FAILED (reading information from the socket failed), whilst 80 (0×50) might refer to MBEDTLS_ERR_NET_CONN_RESET (connection was reset by peer). If that is the case, ROOL might be able to map them onto the equivalent DCI4 error (if there is any) in a future release. Please note that the above is pure speculation on my behalf. I have not seen the AcornSSL source to be certain about this, and ROOL has not yet confirmed the meaning of the returned codes.

With the above in mind, I have been able to run a secure connection with a very strict server for the past 5 hours without any glitches.

Timing. I had been playing with the (Wimp_PollIdle) delay for the ENOTCONN loop and apparently ended up with a value some servers couldn’t handle.

Got all test accounts working now.

Another thing to keep in mind: I had one account with an incorrect password. Apparently the server just dropped the connection without any message, because all I got back was an error &813F26 “Socket error (code 76)”.

I realise you may be using the emulator, but for RISCOS there is an openssl binary inside openssl-dev package at riscosinfo.
I use it occasionally for obtaining the secure certificates from secure mail servers and extracting a fingerprint for my port of fetchmail.
Fetchmail is compiled with libssl so the errors are relayed from the ssl connection and quoted accurately by the fetchmail error output.
I guess this is standard fare using linux signals or something.
Note, in the openssl (shell) manual, it says that the source code for s_client is old and there may be better clients around to model from.

Edit: The error from openssl binary regarding config file can be ignored, or if a config file is required, use

*Set OPENSSL_CONF /linux/path/to/file

and if set to /dev/null or a findable empty file then openssl will treat the config file as being found.
The relevant openssl.c and sample openssl.cnf files are in the apps directory of the original openssl source archive. (may not be packaged on riscos.info)

No, I believe Frank is using a Linux client (specifically openssl) to make a connection to the server he’s testing against to prove the validity of elements of the equivalent commands using the new beta version TCP and SSL support from ROOL.

but for RISCOS there is an openssl binary inside openssl-dev package at riscosinfo.

Which may well work for somethings, but it doesn’t test the ROOL package that is destined to be the default RO5.x built-in-to-the-OS support.

Yes the subject I was replying about. Just saying as there may be people using native RISCOS machines and they can also use the openssl s_client client (to be accurate, linux openssl is a shell for many commands, a mistype at the prompt displays them all.)

Does AcornSSL_Ioctl actually support FIOASYNC? The EINVAL (&20E16 => Unix error 22) returned suggests it doesn’t. If it did, I think the change you made should be enough, provided you don’t use socket descriptors but AcornSSL handles when you call SocketWatch_Register.

In the meantime I’ve run some tests with AntiSpam. No new issues, just an existing one – which is a show stopper, unfortunately: it’s effectively useless for non-interactive work, as it wants user interaction when there’s a problem with the certificate.

Pity.

Edit
Temporary solution (aka bad hack): kill the module task and you eventually get a Handshake error in state 9,984.

The stated reason for this not being an option is to ensure “RISC OS is properly secure and compliant with certificates”. However, as Frank says, it is a showstopper for email really. It is one of a few reasons we’ve still not got a happy Hermes on AcornSSL :( The best compromise I can think of is to prompt the first time, and offer “accept”, “reject” or “always accept”.

That way, it can be done once, and approved, and then used transparently from then on. You still get the security of a warning, but once you’ve said “OK, proceed”, you need (optionally) only do this once.

Unfortunately, it is probably significantly more code in AcornSSL, as really this needs to be offered on a per-application basis, to avoid you accepting a certificate in one program and inadvertantly affecting another. Although, if push comes to shove, that’s probably not the end of the world, as most situations (for email) will be self-cert setups as Frank mentions.