Resolver 0.73 is broken

Charles, thanks for your interest and your input into this case.

just do DHCP

Static IP with DHCP reservations on the router.

Why? Easy. Livebox boot – measured in minutes. Pi boot – measured in seconds.

When I set up everything, DHCP only worked in RISC OS for a few seconds at boot.
I think it can happen at other times now ¹ but static addresses are just simpler.

I also have the ROD stack

I’m using a slightly older ROM, but if I hadn’t been, then this is why I’d not have noticed.

¹ Of course this isn’t so useful if DHCP can be invoked by the network connection coming up, as that’s the Vonets widget, and that too boots much faster than the router.

One difference between DHCP and manual IP addressing, for me, is that my router’s DHCP server does not allow aliases for host names, while the Hosts file and Resolver clearly do.

Static IP with DHCP reservations on the router.

Why? Easy. Livebox boot – measured in minutes. Pi boot – measured in seconds.

One of the reasons that the router and the NAS are connected to a UPS :)

my router’s DHCP server does not allow aliases for host names, while the Hosts file and Resolver clearly do

That I can go with. CNAME functionality is in proper DNS servers and standard software on home routers doesn’t do that

Mmm – I wonder if the TV would work from a UPS.

Wood fire – Candles :-|

are connected to a UPS :)

Same here, but that’s a more recent thing borne of a great annoyance at the thing rebooting at the slightest blip in power, something they the Pi simply shrugs off.

I wonder if the TV would work from a UPS.

Mine’s a 12V output. Because of this (no losses going up to 230VAC and down again), it can run for quite a while. I didn’t notice a half hour power cut in the summer as I had the light off (shutters open) and was using my phone to access the net. ;)

As to the TV, if it’s a flat panel then it is basically the same idea as a monitor, and a large UPS can run those as well as the base computer. But for how long depends upon the rating of the UPS as well as the amount of loss involved in step up (in the UPS) and step down (in the TV) of the power.
A 300VA UPS with a good battery ought to run a 50W load for about 50 minutes, but it isn’t linear, 75W for 29m, 100W for 18m. (source)

The Resolver 0.73 is I believe closed source and belong’s to ANT Ltd.

But the note on the information page regarding the RISCOS Development webpage for the new TCP/IP says:
New Open Source Resolver and MBufManager modules to replace closed-source versions. These are compatible with the older stack too, to allow developers to test new software (eg. IPv4 and IPv6 aware applications) on all machines.

Has this combination been tested?

I also note on ROOL home pages some changes to the ROOL TCP/IP stack recently as well.

These are compatible with the older stack too, to allow developers to test new software (eg. IPv4 and IPv6 aware applications) on all machines.

Define “all machines”
I’m pretty sure it was noted somewhere that the module isn’t compatible with the RPC or the RPCEmu.
Yep, I know the Luddites need to move on and get themselves a recent machine like the rest of us, but how many of us do quick checks of various items using RPCEmu?

Probably if you have a fast PC and the habit of keeping it on…

…I find just using native silicon is easier and more energy efficient.
Oh, and it’s far ahead of a RiscPC class machine in capabilities.

I’m pretty sure it was noted somewhere that the module isn’t compatible with the RPC or the RPCEmu.

I am pretty sure that it was only noted for the main stack and the utils, but not for everything.

Since it is likely that both MBufManager and Resolver are based on stack-independent code (MBufManager probably clean-room implementation, Resolver possibly based on c-ares or something?), I would guess that they might be compatible. If the provided binaries are, is of course a totally different question. And if they were tested at all in this combination…who knows. I use RPCemu only in a RO4 setup, so I will not be the one wasting time on recompile/test.

Since it is likely that both MBufManager and Resolver are based on stack-independent code

I can confirm that Resolver works with the old stack at least on a PI4 (I havn’t tested on RPCEmu). You just have to load modules CryptRand, SLAAC and Resolver within the ROD archive ( Install.Boot.Resources.OBSD.rm(v5)).

That said it is also using the ROD Resolver’s new API for IPv4/v6 independent address resolution that led me to the discovery of the incompatible layout of struct addrinfo between the ROD stack and ROOL’s new TCPIP beta library.

Note: since then I have received a test Resolver module that allows to specify whcih layout of addrinfo to use.

I use RPCemu only in a RO4 setup, so I will not be the one wasting time on recompile/test.

Saving you all the effort, I tried loading it on RPCEmu, and it complains about “undefined instruction at &202874ec” you can get it to fail differently (abort on data transfer) if you load the ACE ARMChip module.

So, not suitable for RPC/RPCEmu is probably the “lesson learned”¹ from that one. Not that I was expecting it to support multi-decades old kit and emulations thereof.

¹ Just for you Rick, because I know you love that wonderful management speak ;)

it complains about “undefined instruction at &202874ec” you can get it to fail differently (abort on data transfer) if you load the ACE ARMChip module.

It would be interesting to see what instruction is failing. If you (or anyone) sees this again, could you post the actual instruction of the undefined instruction error (i.e. without ACE module loaded).

This can be done with the star command *memoryi address +4. Replacing address with the hex value after the “undefined instruction at” error.

I could then check if there is a mistake in my ACE module.

Saving you all the effort, I tried loading it on RPCEmu, and it complains about “undefined instruction at &202874ec”

You seem to have skipped the “recompile” step.

You seem to have skipped the “recompile” step.

Yup. The question was whether what had been released was suitable for all – it isn’t.
A secondary, unasked although possibly implied, question is would a recompile with appropriate legacy setup produce something that worked on legacy machines.

A secondary, unasked although possibly implied, question is would a recompile with appropriate legacy setup produce something that worked on legacy machines.

You even quoted parts of the posting that asked that question (although I didn’t include a question mark and left that as an exercise for the reader), including the word “recompile”.

Forgive me if I’m mis-understanding the last few posts. If the question is “does the new resolver etc work on RPCemu / old stack”, I believe the answer is “yes, but you’ll want to use a recent beta – please drop us an email and we’ll send you a copy”. Or compile your own from the sources, but easier to just get an RPCemu-safe version of the stack.

The stack has been working on pretty much all hardware since May (v7.02 beta), but we have had several minor hold ups in getting 7.02 a “release” tag. Nothing that stops it being useful, but this is the downside of wanting to deliver something that is great for everyone, whilst simulatenously having to softload on top of unpredictable base !Boot sequences and network setups. There have been several public beta releases of 7.02 in the meantime.

Or compile your own from the sources

Are the sources available somewhere?

They are often included with the betas, and can be requested as described on the download page on the website. It’s licensed under CDDL.

Blob resolved. Resolver 0.74, in today’s betas, is good here. Thanks.

Thanks, djp, I’ll look it out this evening.

I’ve given today’s build of RO a bit of a thrash, especially the Resolver module, whose version 0s 0.74 (12 Dec 2022). It works fine for me. RasPi 3B+.

For my curiosity, what went wrong? Did it require a new binary blob? Who has the source to fix it? (No, I don’t want it; this is merely to satisfy my curiosity.)

For my curiosity, what went wrong?

The old code was looking for /etc/hosts rather than InetDBase:Hosts which didn’t work all that well.

The old code was looking for /etc/hosts rather than InetDBase:Hosts which didn’t work all that well.

Thinking about it, if you look at what Charles said earlier the strings output says it has /etc/hosts there and not the normal RO style path to hosts

So, Gerph being his usual educational self. His answer said not just that it was broken, but also gave the evidence of how it was broken.

Last year I created a video of how this bug was found, as I felt it was a simple example of how you might investigate the problem with RISC OS Pyromaniac. Largely this was very similar to the description I posted, but it’s often easier and nicer to see the process in a video.

You can find the video on Youtube and on my presentation site: https://presentation.riscos.online/debugging/index.html