ROD TCP/IP Stack 7.04 released

We are pleased to announce the release of v7.04 of the ROD TCP/IP stack supporting IPv6 and many other modern network technologies.

v7.04 is primarily a maintenance release, resolving a few small issues reported by users. It also adds support for the gigabit ethernet controller used in RK3399-based boards.

Bug fixes:

ShareFS no longer disappears momentarily when IPv6 receives address change notifications
Running with DHCP enabled, but no network cable connected no longer results in locks after extended periods

New features:

Support for RK3399 gigabit ethernet devices
Many new entry points to expose wifi capabilities

Much of this year has been spent readying the stack for Wifi, so one important aspect of 7.04 is to bring together all the various strands of work that have been done to create a formal release again. Work continues to progress on the Wifi front, and we hope to bring you more news in the new year.

To download v7.04 of the stack, head over to www.riscosdev.com and click on the word “Projects”. You’ll see 7.04 available for download. Full source is available on request – the zip is waiting, just ask.

To install, run the enclosed installation application. It will then install the appropriate vesion for whatever generation of ARM platform you are running.

Happy Christmas and New Year to everyone :)

Thank you for the Christmas present.

I wish everyone a happy Christmas.

I have logged on the RiscOSDev Tickets site that I cannot get the Install app either to replace 7.03 with 7.04 on my Pi 400, nor install 7.04 from scratch (after either auto or manual uninstall of 7.03).

It’s not at all urgent, but I wonder where the problem is.

It in the normal place got to Riscosdev projects click on the link.

I cannot get the Install app either to replace 7.03 with 7.04 on my Pi 400, nor install 7.04 from scratch

Hi Bernard,

I uninstalled 7.04 from my Pi400 , deleted !OBSD in Resources, so it was totally clean and then installed 7.04 again, from the ROD projects page, and it installs.

I then uninstalled it again, plus manual delete of !OBSD, and then installed 7.03 and then upgraded to 7.04, without any manual intervention, and again everything is OK.

Mine is an early 4GB Pi400, not with the later Lan chip, with updated firmware and RISCOS 5.29 (03-Jun-23) running on it.

To test it is installing the right stack I do a *help Internet.

I also have 1.21 of PiTools running as I know some versions of that causaed issues.

@Rob Yes, I am using the !Install app in the 7.04 download from RiscOSDev, hence my surprise that it didn’t work for me, and hence my logging it to the ticket site.

I mention it here not least because it helps publicise the ticket site.

@Doug Thanks, I’ve been doing similar things to you without the expected result. I tend to use Verma to check loaded modules’ versions, but of course *Help Internet is also useful.

PiTools 1.21 is running.

Hi Bernard,

I’ve updated the ticket with my experience.

I use !Verma as well and again it shows everything updated correctly.

Couple of other things:

Have you got Delegate installed and set to protect the entire System or sub elements of it?

Have you got !Boot hidden or Choices moved out of !Boot as per Rob Sprowsons updates?
Doug

There is an issue with 7.04 for some users. I have been working with John Balance to help track down the issues.

Within !OBSD.bin is an app called sysctl apparently this needs a newer version of CLib (SharedCLibrary) at least 6.20 but my 4te2 was only loading 6.13 ! and my ARMX6 oddly 6.15. I fixed the ARMX6 by simply updating the CLib to 6.22 and checking that was actually getting loaded at startup. 7.04 TCP/IP now worked on the ARMX6. But the same trick on the 4te2 did not. John Balance supplied me with a little program to install an older sysctl using the older CLib it all now worked on the 4te2. Still being investigated why this is the case.

Within !OBSD.bin is an app called sysctl apparently this needs a newer version of CLib (SharedCLibrary) at least 6.20

Thanks for that Chris as I have SharedCLibrary 6.20 installed on my Pi400 and all my other systems as I have updated the disc image to later versions than supplied with 5.28, when I did ROM updates.

Delegate Boot protection didn’t make any difference here so I guess the SharedCLibrary one is something for Bernard to check on.

Just proves the wider the testing the better end result.

We’ll follow up problems individually with users after Christmas, but in the meantime, if you’d like to write to the andrew@ email address, he’ll try to send out the fix for the sysctl issue with older OS versions as family time permits.

Andrew Rawnsley has just said to me I can provide the fix supplied by John Balance on request as an interim measure for the older sysctl on request. So if you need it let me know your email address. I will do this on a best endeavour basis as it is Christmas Eve/Day.

After install of 7.04 I get an error related to an out of date CLib.
help modules shows:
C Library 6.11 (22 Nov 2021)

There is a later version (6.22) in 500.Modules
I thought this would be loaded automatically if needed

C Libary
There is a bug in Clabry v.6.11

To be taken into account it is necessary that in the Run file we find:

RMEnsure SharedCLibrary 6.20 Error This !Boot structure requires SharedCLibrary version 6.22 or later

This library must be loaded as soon as possible, version 6.20 for this example must be > 6.11 for the one in 500.modules to be loaded.
Normally this modification is done automatically by installing HardDisk4.

There is a later version (6.22) in 500.Modules I thought this would be loaded automatically if needed

No, only if you have installed it correctly.

The SCL can’t be updated “on demand”, as it can easily crash the whole system if done more than once. Installing an update to the SCL must be done in a specific way, so that the updated module is loaded very early on in the boot sequence, before any clients have registered with it.

After that, all that clients can do is test for the active version and error if it is too old. If they try to load an update on the fly, they risk bricking the system under you.

The problem is, I can’t find the an update which shows how this should be done. The lines go into !Boot.Utils.BootRun, don’t they? Can anyone confirm?

@ Steve

The problem is, I can’t find the an update which shows how this should be done. The lines go into !Boot.Utils.BootRun, don’t they? Can anyone confirm?

AFAIU, yes, the line should go in BootRun (where also VProtect should be loaded too for older versions of RISC OS), however if those files should not be edited by a user, isn’t the case that the official Boot process needs to be updated?

I understand ROOL seems to still follow old Acorn “rules”, but is this still necessary for the SCL on RO 5?

Right now it seems that the first SCL dependent App that gets loaded, because the user added it into their customisable boot process part, loads the SCL. If only one SCL is available at every given time, then this should work ok in most cases (not all obviously), but this doesn’t seems to be the case…

The problem is, I can’t find the an update which shows how this should be done. The lines go into !Boot.Utils.BootRun, don’t they? Can anyone confirm?

The first instance I know of that does an RMEnsure of Clib is in Run, but, here, since that is RMEnsuring a version that is lower than the 6.22 in the ROM nothing happens.

I assume that anyone running a nightly beta won’t see the issue and when v5.30 makes it onto our collective machines the issue will go away.

Meanwhile, for those running a ROM that doesn’t have 6.22 the change would be in the Run to change the RMEnsure to read:

RMEnsure SharedCLibrary 6.22 Error This !Boot structure requires SharedCLibrary version 6.22 or later

and ensure your !Boot is up to date with the beta HardDisc download.

Right now it seems that the first SCL dependent App that gets loaded, because the user added it into their customisable boot process part, loads the SCL.

It shouldn’t be, because no applications should ever load the SCL on demand. The commands used in applications’ !Boot files should be along these lines (taken from here, which in turn came from some Castle/ROOL documentation):

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib
RMEnsure SharedCLibrary 5.34 Error This application requires SharedCLibrary 5.34 or later

The 5.34 is the minimum version of SCL that the application can work with, while the 5.17 is the first version that was “32-bit”. So an application will soft-load the library if the machine currently has only a “26-bit” version of the library running. If any “32-bit” version is present, however, it will never do an update – it will simply complain.

If only one SCL is available at every given time, then this should work ok in most cases (not all obviously), but this doesn’t seems to be the case…

I think the problem comes when a new version comes out. If a user doesn’t update their library, but does try to use an application which requires the newer version, you would get a sequence where the same version was soft-loaded twice… which probably won’t end well unless the OS spots the version numbers in RMLoad and aborts the operation (which I don’t think it does).

Even though it’s the same module, won’t the new copy end up in a different bit of RMA from the old one, leaving all of the clients which had registered to the old copy dangling into thin air?

Edit: And for clarity, soft-loading a newer version over an older soft-loaded version is also bad, for exactly the same reason. The new module replaces the old, the old module’s space in the RMA is freed, and then over time all of the subs linked into the older version start to fail in unpredictable ways.

Whoops, sorry I overlooked ! Boot . ! Run

Yes the RMEnsure is in there and yes, it requires 5.43, which in this particoular case will most likely cause the problem down the line, if the required one is not the one being loaded (aka the one reachable as first).

I think the problem is that people are running beta applications with higher Clib requirements, but not everyone doing so is updating their boot sequence/ROM – for general info Clib 6.22 is November 2023
From what Jean-Michel said earlier, CLib v6.20 is April 2023 vintage or earlier, so any ROM from then until now will probably fix things

Yes the RMEnsure is in there and yes, it requires 5.43, which in this particoular case will most likely cause the problem down the line, if the required one is not the one being loaded (aka the one reachable as first).

If I recall, the sequence is:
Look at the Clib from ROM if it doesn’t match/exceed the RMEnsure requirements, look in the set of module directories starting with one that matches the OS and then check for the required module in descending order of directory

Edit It would possibly improve things if the Run file was updated in the Beta HD4 to RMEnsure 6.2x as, even though the boot itself doesn’t require that level at present, clearly newer apps do and updating Clib after the boot has always been a bit of an “interesting” experience.

If I recall, the sequence is:
Look at the Clib from ROM if it doesn’t match/exceed the RMEnsure requirements, look in the set of module

So, to be clear, the RMEnsure in the ! Boot . ! Run , only checks if the ROM one is match/exceed 5.43, if it doesn’t only throws an error and stop the boot sequence (so again the loading of a more recent one either doesn’t happen at all or is left to whatever App that does NOT behave in a standard way), hence Steve’s idea to me still apply, but again should be a standardised approach vs “let me do this on my own”.

Edit It would possibly improve things if the Run file was updated in the Beta HD4 to RMEnsure 6.2x as, even though the boot itself doesn’t require that level at present, clearly newer apps do and updating Clib after the boot has always been a bit of an “interesting” experience.

I agree to some extent. In the sense that the Run still has no idea of where !System is, that is defined in BootRun where also Path and other Modules are loaded. So, again to me it looks like it should be checked and loaded in BootRun (hope my English is making sense).
So, IMHO, your idea is good, but I think it should be applied to BootRun and the issue is, we need a utility program that loads the disc based SCL only if it’s more recent than the one in ROM.

For what concern the specific bug, that will require to update the SCL on disc, which obviously should require ROOL to give us a notice (given we still don’t have a working auto-update, which I can finish, but then I’ll get folks having opinions against, so it’s still in the list of things to do for myself and to share only with who wants it too, while for this we need a standardised approach)

Edit It would possibly improve things if the Run file was updated in the Beta HD4 to RMEnsure 6.2x as, even though the boot itself doesn’t require that level at present, clearly newer apps do and updating Clib after the boot has always been a bit of an “interesting” experience.

Yes,I think the update should be done through HD4 updates, which was not the case in April 2023.
The boot.!Run :
Rmensure SharedCLibrary 5.43
While in 500.system of HD4 content there was version SharedCLibrary 6.19, which was therefore never loaded.

This would avoid errors when manually editing the Run file.

Note:I have a similar problem with the SCIFS module, but I couldn’t find how to replace the ROM version.It’s not easy because the SSD disk is my Boot disk…
The module generates a problem if I want to use !SystemDisk. I contacted Elesar Support and with their help there is a good chance that the problem comes from the version of the module (1.36).
(I couldn’t find the newer version on Hardisk4, that would be a good way to update, just an idea!)

RMEnsure SharedCLibrary 6.20 […]

First question, does it need that version of CLib?

The 5.34 is the minimum version of SCL that the application can work with

I think most people just copy the boilerplate without looking to see which C library version is actually needed.

I tried to work out what each version added https://heyrick.eu/blog/index.php?diary=20200318
It’s a few years old so out of date, but this sort of thing ought to be in a wiki so a person can know to ask for 5.52 (or later) if they want 64 bit maths, 5.76 for a working scanf(), etc.

Given the “issues”, I personally feel that the minimum version that should be checked for, at all, is 5.44.

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib RMEnsure SharedCLibrary 5.34 Error This application requires SharedCLibrary 5.34 or later

Please don’t do this.
One shouldn’t ever attempt to blindly RMLoad any version of CLib in a !Run file as there’s no way of knowing if the library currently loaded is, itself, a softload. But for whatever reason, the ability of a softload CLib to refuse to quit has never been added, so this problem remains.
If CLib isn’t a new enough one, just error out. Let the user sort out upgrading their system appropriately.

Use this instead:

RMEnsure SharedCLibrary 5.72 Error Sorry, <your app name> requires SharedCLibrary 5.72 or later.

First question, does it need that version of CLib?

yes,I discovered the problem with one of my programs, and it really came from the SharedCLibrary (v 6.15)

So, to be clear, the RMEnsure in the ! Boot . ! Run , only checks if the ROM one is match/exceed 5.43, if it doesn’t only throws an error and stop the boot sequence (so again the loading of a more recent one either doesn’t happen at all or is left to whatever App that does NOT behave in a standard way

Yeah, I wasn’t paying attention. That does indeed just abort the boot if the condition isn’t met.
The problem is that when you have something like Rick’s “Harinezumi” in the startup it’s looking for a Clib, so the CLib needs to be inserted very early.
Maybe the next line in Run would RMLoad the newer CLib you intend to use instead of the one in ROM?

So, IMHO, your idea is good, but I think it should be applied to BootRun and the issue is, we need a utility program that loads the disc based SCL only if it’s more recent than the one in ROM.

Question there:- does BootVars use CLib? I think it does.

The sequence is
Run
BootVars
BootRun

So by the time you’re at BootRun there is already one item in the sequence that has used/is using CLib

Overall, the usual PITA of changing CLib on the fly and watching which bits object to having the rug pulled from under their feet.