TCP/IP bounty beta release

Just to clarify what I meant…

Please bear in mind that I haven’t done/needed-to-do any socket coding myself, so I’m basically giving second hand information. Since I hope we don’t live in Sparta, please don’t kick the messenger! ;)

There are a few oddities. Small ones (I think) include fussiness over the order in which you create the socket and mark it as non-blocking. The logic was seemingly reversed compared to ordinary sockets.

Socket_select was trickier, because normally it only returns (non-zero?) if there’s data waiting to be read. With AcornSSL, it can return non-zero when there isn’t incomming data. I think I have that right. It is covered in the documentation, but it means you need to code your SSL routines with that in mind.

We also had issues with socket peek-ing. This is designed to allow you to check if there’s data in a socket without modifying/removing it. We found that in certain cases the (SSL) socket would be emptied after a peek, where a regular socket wouldn’t. I believe Alan was able to re-code Hermes not to use peeks on SSL sockets.

Please note – some/all of these may have been resolved. I just thought I’d explain a few of the things we encountered during the last 9 months. Alan would be able to explain more.

Note – for most people, this stuff won’t matter. Esp if you’re writing new code. For people porting code, they probably won’t be using AcornSSL anyway. The main problem is that we’d intended to produce a simple “shim” to allow older programs using SecureSockets to transparently use AcornSSL. However, this is likely to be considerably more complex, and has had to be shelved for now.

Further update – beta 3 of NF 5.5 (which has optimisations to extend timeout delays etc) is now working better on RiscPCs, but still can’t do more than a handful of simultaneous SSL connections (tester is using 9!), but they seem happy fetching sequentially. The full set work in parallel on an “ordinary” VRPC laptop now, so performance seems to play a factor still. We’ll keep tuning where possible.

It’d still be useful to have other tests done on RiscPC where multiple things are being fetched, but short of writing test code, it could be tricky to simulate.

Hi Andrew

Downloaded the latest Beta and it does seem better even on my ARMX6 and in particular with simultaneous SSL downloads.

I’ll see if I can get time when I am feeling better to test on the RiscPC I did the other tests on.

OK so done some testing with the latest Beta on a RiscPC, Kinetic, Unipod, VPod and RISCOS 6.20.

Seems to work a lot better and only one instance of Connection lost which was when it was using the Unipod 100Mb ethernet connection.

I did try the standard 10Mb network card as well and no issues there.

Both occasions doing 5 simultaneous downloads.

That’s really helpful, thankyou :) Sounds like we’re heading in the right direction!

Sounds like we’re heading in the right direction!

Indeed. SSL v1.04 made it into the build sources today so tomorrow will see it available to all in the beta HardDisc download.

All good things come to those who wait.

Thanks to ROOL, the person(s) doing the work, those that contributed money to this bounty and a big thanks to all the testers as well.

Now the next step is the big one so with Wakefield coming up please save some money for the 2nd part of this important bounty.

All good things come to those who wait

Persistence: “check”
Patience: “er, forgot to pack that”
:)

So now the official AcornSSL is available I decided to check it out but before doing so I compared the module sizes between the RComp supplied 1.04 and the one generated by ROOL and on the downloads page at there is a difference.

RComp AcornSSL – size 188948
ROOL AcornSSL – size 189108

The ROOL module reports help string:
AcornSSL 1.04 (26 Jan 2018) mbedTLS 2.16.1

Whilst the RComp one reports:
AcornSSL 1.04 (26 Jan 2018) mbedTLS 2.16.0

So it seems that the ROOL module has some later mbedTLS changes incorperated in to it.

The mbedTLS page suggests the update was made available on 26th March.

I’ve now installed the ROOL module overwriting the RComp supplied 1.04.

how things have changed (for the better) if it really is mbedTLS 2.16.1 then that’s security less than a week old!

OK, so being testing this all day on both a ARMX6 and also Kinetic RiscPC with RISCOS 6.20 and no problems.

This is with NetFetch 5.49 Beta 3.

If anything it seems a little quicker on both machines.

The ARMX6 had 8 simultaneous email downloads each time and the Kinetic 5.

The other thing is that the occasional issues I saw on the ARMX6 and Kinetic with failure to initiate Hermes fetching on a manual request, which resulted in me having to click on the Transfer Mail panel icon again, haven’t been seen when using the ROOL 1.04 AcornSSL module.

Perhaps RComp should update the Beta to include the latest AcornSSL module after doing their own testing?

The ROOL module reports help string:
AcornSSL 1.04 (26 Jan 2018) mbedTLS 2.16.1

Whilst the RComp one reports:
AcornSSL 1.04 (26 Jan 2018) mbedTLS 2.16.0

Shouldn’t the ROOL issued version be labelled 1.05 if the mbedTLS library has been updated?
In which case R-Comp would be testing a known updated version.

Edit: Obviously I got to this before Nemo, otherwise we’d have the extended grumbles about different versions and same version number…

Shouldn’t the ROOL issued version be labelled 1.05 if the mbedTLS library has been updated?

Well depends if they are aligning to the major releases of Mbed then perhaps 1.04 is aligned to 2.16 stream and hence a minor up issue to 2.16.1 should mean it is 1.041 or 1.04b or 1.04.1?.

As to RComp version then rather than the beta 1.04 supplied my thoughts should be that they supply the official ROOL version of 1.04 that now has it’s release.

I have sent details of my post to their programmer so hopefully this will get feedback one way or another.

The fact we are now getting quicker updates of the module is to be applauded but it does throw up it’s own issues for the likes of RComp and others in that they are perhaps used to a rather more leisurely pace of change based on years not potentially days/months.

it does throw up it’s own issues

Maybe time to revisit what ought to be in !System and what ought to be elsewhere?

Might also be worth adding a new command to Installer → *Install_Module <path> which will so whatever is necessary to install/update a module in !System.
[difference from *Install_Update is that it won’t take a destination, it’s up to the Installer to do that]

Help to get “global resource” modules out of application resources. ;-)

Well depends if they are aligning to the major releases of Mbed then perhaps 1.04 is aligned to 2.16 stream and hence a minor up issue to 2.16.1 should mean it is 1.041 or 1.04b or 1.04.1?.

Perhaps. I think we seem to be on the same page with respect to denoting different versions properly.

The fact we are now getting quicker updates of the module is to be applauded but it does throw up it’s own issues for the likes of RComp and others in that they are perhaps used to a rather more leisurely pace of change based on years not potentially days/months.

Well ideally there would be a known stable version and the likes of a 1.04.1 would only be in the beta releases. Moving along to a new stable would be after suitable testing of the beta.
Perhaps some subversioning of the “stable” disc is required to make sure the latest known secure & patched SSL module is in the latest stable disc.

One thing that I don’t think should happen is individual suppliers putting out a unique version.¹
NB. Not having a go at R-Comp, just that best use of testing and community support resource² is to make sure everyone is working with the same software set, which is best achieved with the software coming from one, and only one, repository.

Look at the numerous variants of Zap or to a lesser extent PopStar to see where it can lead.

¹ In this instance I can see one difficulty, which is that the R-Comp supply to the customer was:

1. Assumed to be merely a copy just in case the user didn’t have a version via another route (ROOL)
2. Included because the user might not be using a ROOL OS and HardDisc/Boot.

I’m not sure how you deal with the latter, !Store pointing at a ROOL resource perhaps?

² tag, we’re it

# Included because the user might not be using a ROOL OS and HardDisc/Boot.
I’m not sure how you deal with the latter, !Store pointing at a ROOL resource perhaps?

Replying to myself, but I think this is another aspect of the !Boot update problem which has been with us for an awfully long time. These days changes happen more frequently so the pain occurs more often.

I say “pain” but provided I remember to do !Boot updates with a “Merge” after I’ve deselected !Boot.!Run I don’t find Harinezumi not running at boot. That’s one item, I’m sure other people can nominate other items.

Well depends if they are aligning to the major releases of Mbed then perhaps 1.04 is aligned to 2.16 stream and hence a minor up issue to 2.16.1 should mean it is 1.041 or 1.04b or 1.04.1?

I think there are apps that require version numbers to be simply major.minor or else they won’t work correctly.

They are just numbers. Let’s keep the whole process simple.

I think there are apps that require version numbers to be simply major.minor or else they won’t work correctly.

Is rmensure one such App?

rmensure basic 1.75.1 echo this fails

I have just uploaded beta 4, which is effectively a release version of NetFetch 5.50/Hermes 5.50. This incorporates latest AcornSSL etc as well as release builds of Hermes and NetFetch. Let me know if there’s anything show-stopping, please.

I’ve written a small note for super-demanding users running legacy kit, but thanks to Doug and others, it seems like only the most demanding situations will cause any trouble, and frankly, if your email needs are that demanding, using 25 year old systems probably isn’t ideal anyway.

Thanks for the latest Beta.

I’ve downloaded it and tested it on my ARMX6 and all seems well so far.

I’ll see if I can get the RiscPC out again for some more testing in the next day or so.

Ok, tested it on a Kinetic RiscPC with 6.20 and using both the Unipod 100Mb and EtherH 10Mb Lan connections and it seems OK.

It is obviously a little slower on the EtherH card but seems fine with 5 simultaneous downloads.

Also no issues with it on the ARMX6.

I had occasion to use an Android SSH terminal app today, which made me wonder if the new AcornSSL module gets us any closer to having a viable modern vesion or equivalent of NettleSSH?

There’s probably some mileage in modifying Hearsay 2 to use a network connection instead of a serial port.
I think the other free options suffer from being ports over from Linux and the graphical baggage of that to make them a bit heavyweight or miss out on the multitasking aspects.

There’s probably some mileage in modifying Hearsay 2 to use a network connection instead of a serial port.

You can – simply attach it to the telnet blockdriver (if it isn’t set up like this or if the box):
https://www.heyrick.co.uk/blog/index.php?diary=20150101
(note – the address is now telnet.arcade-bbs.net)

I think the other free options suffer from being ports over from Linux

Other ports? Isn’t it just Nettle and Connector?

Connector (native) doesn’t want to talk to the telnet driver. No idea why, but I note that my own homebrew terminal doesn’t want to either, maybe some init that we’re both missing?

Nettle is “okay” but it does suffer from some bugs eccentricities in its ANSI rendering.

Android SSH terminal app today,

Any of them support OEM/PC-ANSI/VT-102 yet? VX Connectbot is quite nice and does all the colours and such, but I’ve yet to find one single free terminal that can be switched to use the correct character sets, namely the VT102 character set:

And/or (but especially) code page 437 as used by the majority of ANSI BBSs:

Ooh! A notification has just popped up. New season of Cloak & Dagger. So, um, bye… <drops EVERYTHING>

You can – simply attach it to the telnet blockdriver (if it isn’t set up like this or if the box):

Must pay more attention, hadn’t registered that. Needs checking out on an SSL setup.
I quite fancy working on a RO machine and querying the switches at work¹ (needs the hardware VPN of course, unless someone gets a full OpenVPN port done)

Other ports? Isn’t it just Nettle and Connector?

I was thinking of stuff like OpenSSH(command line) and Putty(ChoX11 interface library and old GTK 1.2 libraries) which both have aspects that leave them sitting in the discard pile.
Specific failings after a bit of research at riscos.info

Connector (native) doesn’t want to talk to the telnet driver.

Given the lack of security in the telnet protocol that’s probably a bonus

A notification has just popped up.

I get those. Non-maskable interrupts :)
She sits across the room in the comfiest chair (if the cat hasn’t mounted a takeover bid).

¹ The upside of Cisco switches being that it’s most definitely a command line access (cos Cisco can’t do a decent GUI to save their life.)