ROD TCP/IP Stack 7.04 released

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

Hummm looking at the disassembly, yes it seems to be calling SCL functions. But it’s something that doesn’t keep running or being loaded as a module, so I am not sure it will cause problems…

If you look at ! Boot . ! Run you’ll quickly see that BootVars is loaded, but then it returns and BootRun is loaded after.

If you look at ! Boot . ! Run you’ll quickly see that BootVars is loaded, but then it returns and BootRun is loaded after.

I was being idle and following the flow diagram for RO4.02 (collected from the stand at the Birmingham show in pre-history I think) and just shows a little loop from BootVars to BootRun
Plus, Harinezumi substitutes for the BootRun command in Boot.!Run so sort of an incentive to get any CLib stuff out of the way before that

Well in that case I guess a small portion of BootRun has to be moved in Run, but it’s really something that needs to be thought through, because, remember, ! Boot . ! Run will be executed also when trying to access !Configure. Unless one wants to change that.

I have a feeling that the “RMEnsure … Error …” is there also for this reason.

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

That doesn’t matter, so long as that thing (those things) are happy with whatever is in ROM.

You get one shot at soft-loading the SCL. When it moves from ROM to RAM, anything already registered with the ROM version remains linked to the ROM routines. That’s fine, because they’re in ROM: they don’t move, even if their module is replaced by one in RAM and so becomes dormant.

The problem is if you try to replace it a second time. This time, you’re replacing a RAM copy of the module with another RAM copy, and that’s the problem: the old version doesn’t hang around to honour any stubs that were linked to it whilst it was active. The memory is freed and at some point, when it gets reallocated, interesting stuff starts to happen as soon as the affected stub routines get used.

So the aim is to get in early on, before anything that isn’t well embedded into the Boot sequence tries to use the SCL¹. But if things like Harinezumi or BootVars use the SCL, we can probably assume that their authors were aware of the issues involved… :-)

¹ Because we don’t trust it to behave sensibly, basically. :-)

Can I clear up a couple of things regarding the update to the new stack. The actual cause of the issue is a newer ‘sysctl’ has changed the way it works and the version as supplied by default requires a newer SharedCLibrary.

The nightly HardDisc4 has a newer SCL 6.22 which works with the newer ‘sysctl’. The boot.Resources.System.Run in the nightly beta HardDisc4 has also been updated to cater for a newer CLib by default.

For those that do not wish to update their SCL for the time being I have a little zip file with a version of the ‘sysctl’ that works with an older SCL. If this is required please let me know. (This is approved by ROD and John Balance).

we can probably assume that their authors were aware of the issues involved… :-)

Nothing to do with me!

Boot’s Run file contains this prior to where the Harinezumi patch goes:

Run <Boot$Dir>.Resources.!System
RMEnsure SharedCLibrary 5.43 Error This !Boot structure requires SharedCLibrary version 5.43 or later

And that call to run System, it does this (amongst many other things):

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 5.66 RMLoad System:Modules.CLib

That’s probably the best place to patch in loading a later version of CLib, although a fair question is to ask why it’s not programmatically created in order to load the versions of modules actually present (as 5.66 is quite old now).

So, by the time Hari starts, CLib may have already been updated.

I have a little BASIC patch as the first item of my Boot Run file. Look at the ROM CLib and look at whatever is in System (500.Modules) and if the CLib on disc is later, force load it before anything else.

Because we don’t trust it to behave sensibly

Yup. All these years of annoyance because the damn thing won’t just say “not gonna”.

Given how CLib works, there’s really no safe way to quit a softloaded version, it never should have allowed such a thing to happen in the first place.

and the version as supplied by default requires a newer SharedCLibrary.

Looking at the history, it seems as if the past couple of versions have been internal tweaks, like renaming something, fiddling with _kernel_kallocExtendsWS, and so on.

For those that do not wish to update their SCL for the time being

It’s not hard. Back in the day the magazine cover discs used to come with new CLibs frequently. The trick is to install it, then reboot. Don’t ever try to softload a softload, it will go kaboom.

it never should have allowed such a thing to happen in the first place

The tragedy being that it is still allowed. Surely these days the absolute best place to load an updated SCL if needed is early in !Boot. And forbid applications from doing anything other than RMEnsure SharedCLibrary required_version Error You need an updated !System (or such) rather than attempting to load a new one which will usually end in tears.

After reading every post and considering all the suggested solutions, notwithstanding some trepidation I opted to change a line in !System

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 5.66 RMLoad System:Modules.CLib

to

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.20 RMLoad System:Modules.CLib

The world has not fallen apart so far, and it has cured the original problem.

.bq

The period comes after the “bq”. ;)

thanks

And that call to run System, it does this (amongst many other things):

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 5.66 RMLoad System:Modules.CLib

Where, jumping back to a Nov 22 install, the older !System contains CLib 6.15, but recent !System updates contain CLib 6.22 (in the 500.modules)
So, can we assume the reported problem was a result of the user not having updated their !System since before CLib 6.20 appeared?

Surely these days the absolute best place to load an updated SCL if needed is early in !Boot.

Apparently it is, and, provided the user has updated their !System install, they have the latest CLib

Edit Looking at John R’s post, that looks like 6.2x is present on his machine, but for some reason it isn’t loaded unless the RMEnsure is set high enough to exclude the non-compliant CLib versions
I thought it looked in the modules directories in descending order…

The period comes after the “bq”. ;)

To paraphrase Eric Morecambe “all the characters are there, but not necessarily in the right order” :)

So, can we assume the reported problem was a result of the user not having updated their !System since before CLib 6.20 appeared?

Forgivable… as unless I’ve missed something, the way to update a RISC OS 5 installation is to download harddisc4 and bugger around inside. The easy PlingSystem update is for earlier systems.

The stable release is offering 6.08, it’s the nightly that offers 6.22. The stable has a file called InSituBootUpdate to update 5.24 to 5.28; but you’re on your own with updating from the nightly.

Honestly, it’s less hassle to just update the ROM ¹ and stuff the disc based resources. :-/
[which makes me wonder – how many people’s ROMs and !Boot stuff are mismatched?]

I thought it looked in the modules directories in descending order…

It… should.

System$Path : Sys:500.,Sys:370.,Sys:360.,Sys:350.,Sys:310., [etc]

¹ Update: Which is what I have just done. Took just over a minute.

So, can we assume the reported problem was a result of the user not having updated their !System since before CLib 6.20 appeared?

Guilty as stated m’lord

I copied the 6.22 Clib from the latest build to 500 and changed the one line in System.Run.

I try to keep my ARMX6 as close to the RComp releases as possible and make simple changes that are easy to back out.

I try to keep my ARMX6 as close to the RComp releases as possible and make simple changes that are easy to back out.

Normally a good way of avoiding self-inflicted problems, still fails the random developer error test though :)

The stable has a file called InSituBootUpdate to update 5.24 to 5.28; but you’re on your own with updating from the nightly.

Yup, back to the old school stuff:
Run !Configure – not available by default from the obvious switcher right-click, because someone is saving that option for a rainy day or something.¹)
Click Boot to find the “Install” select that and drag the !Boot out of the HardDisc zip file and onto the waiting “Merge” box as it now calls itself.

¹ After all, why would anyone want the right click to be different to the left anyway? :(
Of course once you’ve found it, on the middle button most non-RO people forget/don’t know in the first place, you can click the Boot, do an add to apps and add the Configure to Apps by digging deep down in the boot directory tree to find the bit you want and thereafter it’s in a more obviously visible location. Or you can go and find a switcher modifier utility and make it do something different, like show you the configure options you were looking for.
Yeah, why would anyone in their right mind want to make a right click on the switcher icon do something different than the left click? You get used to the middle button on switcher bit, eventually. Still waiting for that to kick in, but I only started on this journey a few decades ago.

More good news: I’ve just got a test app going that receives data from an IPv6-only web site using AcornSSL and BASIC. I don’t think AcornSSL needs to be modified in any way to implement a secure IPv6 client.

That’s a high degree of compatibility that the new stack gives us.

Even more credit and kudos to the ROD people!

Honestly, it’s less hassle to just update the ROM 1 and stuff the disc based resources. :-/

I usually update the ROM (easy, as you say) and do the HardDisc4 image by opening the archive and copying it over my live $ directory. Always worked fine for me. I realise that if there are critical new bits in the PreDesk/Tasks areas, then they won’t be brought in (unless I wipe my Choices.Boot directory and re-boot), but I can periodically check that.

[which makes me wonder – how many people’s ROMs and !Boot stuff are mismatched?]

This thread and that comment just demonstrate why it all needs packaging and people just need to let it update. Don’t manually muck around in !Boot (why would you?!) and just chill out about where stuff lives on your ‘HardDisc4’. Who cares if something is in Apps or Utilities or Diversions? No-one. The path of least resistance is not to fight it.

This thread and that comment just demonstrate why it all needs packaging and people just need to let it update.

+1 Richard, I agree

Don’t manually muck around in !Boot (why would you?!)

Ordinarily, not at all¹ and it is normally a ROM and HD4 update job – which really ought to be automated.
On the subject of automation:- I wonder, should that be arranged as three levels of update:

1. LTS
2. Standard
3. Nightly

¹ Discounting the fiddle to make !Configure appear somewhere more logical

Who cares if something is in Apps or Utilities or Diversions? No-one. The path of least resistance is not to fight it.

After two solid weeks of fighting a Mac mini to get it to do anything at all other than what it thinks is proper. I am inclined to agree. Ars longa, vita brevis, and there are better ways to use the brevis.

For years I used an email tagline “Always fight the Zeitgeist”.¹
In 2024 that ends. I resolve to stop punching the Mac jelly. There is zero chance of landing a damaging blow. But RISC OS is a different matter. There is a fighing chance of tailoring it. I will continue to ask PackMan to put stuff in locations of my choice.

¹ Jim Nagel once asked for the source of the quote. I told him I did not remember; internet searches just returned hits from my email tags.

I will continue to ask PackMan to put stuff in locations of my choice.

I think a lot of the reluctance of users to use PackMan stems from not knowing that this is possible.

Has anyone managed to get IPv6 working on the Pinebook Pro using this stack?
IPv6 is working on my other RISC OS machines. (Which are Raspberry Pi based.)

Before I reach out to ROD or raise a bug report, I wanted to see if IPv6 works for anyone on the Pinebook Pro?

I’d also like to hear what exactly are the symptoms that you’re seeing. If you type *ifconfig -a at the command line, does the command return? If so what does it say? Is there any sign of any network activity, e.g. do you have the ShareFS icon on your icon bar; can you “Show discs” from it? Do the network lights come on at either end of the link?

Hi Dave,
You may remember we had a long discussion about this on ChatCube about a year ago!

Using the ROD stack on the Pinebook Pro, the network link comes up, IPv4 works perfectly, ShareFS works too.
I can browse the web and access the LAN.

If I try to ping an IPv6 host, eg) *ping6 google.co.uk
I get a DNS lookup that returns the IPv6 IP address, then a message;
ping6: sendmsg: No route to host

The same setup works perfectly on a Raspberry Pi, running RISC OS 5.29. (So I don’t think this is a LAN or Router issue)

Output of ifconfig -a;

*ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0×1
inet 127.0.0.1 netmask 0xff000000
ej0: flags=a08843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6,AUTOCONF4> mtu 1500
lladdr 00:0e:c6:84:06:d1
groups: egress
media: Ethernet autoselect (100baseTX half-duplex)
status: active
inet6 fe80::20e:c6ff:fe84:6d1%ej0 prefixlen 64 scopeid 0×2
inet 10.0.0.40 netmask 0xffffff00 broadcast 10.0.0.255
eth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 52:47:33:54:21:fe
media: Ethernet autoselect (100baseTX half-duplex)
status: active

I have also tried setting a manual IPv6, however this produces the same error as above when trying to ping an IPv6 address.