ROD's new TCP/IP stack.

One other thing is that there are no tests, which is something I would like to see for a piece of software this large and complex, although I accept it’s hard to do that on RISC OS.

Particularly if it is hard to test a given system, there should be tests. It does not have to be hard, either. It might be involved, but that doesn’t necessarily make it hard.

Even if they’re only system integration tests, or tests that need manual intervention, such things should exist. I refer people again to the riscos-tests repository at https://github.com/gerph/riscos-tests/tree/master/testcode/ which contains some of the tests I have extracted from RISC OS Pyromaniac.

In particular, note the comment on https://github.com/gerph/riscos-tests which states that tests have been explicitly made available to demonstrate the use with Internet 6 (the prior name of the Internet 7 stack).

And as you suggest, this is exactly the purpose of RISC OS Pyromaniac. During the testing of the ROD stack many undesireable features were found in the stack, and reported. I have not returned to do more exhaustive testing, but for any project – be it RISC OS or not – of an appreciable size, there ought to be tests.

However, this is not a criticism of the ROD Internet stack. It is a criticism of most RISC OS software – I’m equally apalled by the state of RISC OS software. There should be no change made which does not have a test to check its behaviour. Whether that be a small change or a whole new component – indeed it is easier to write tests for new components than for legacy software.

the one component that wouldn’t build is SysCtl

Indeed there is no sysctl in the ROD release.

ROOL to the rescue then :-

*help internet
==> Help on keyword Internet
Module is: Internet        7.03 (15 Dec 2022)

*which sysctl
File: ADFS::Titan4.$.!BOOT.Resources.!Internet.bin.sysctl
*

Indeed there is no sysctl in the ROD release.
ROOL to the rescue then :-

It turns out there are three:

• The one in the ROD tree is a clone of the ROOL one from last year (from 4.3 BSD)
• The one in the current ROOL tree is a fresh port of the one from FreeBSD
• OpenBSD has its own sysctl tool which is completely different, and nobody has ported.

I haven’t studied them in enough detail to know whether this distinction matters or not. There is code in the ROD stack for receiving sysctls from the Socket_Sysctl SWI so I would guess that uses the old RISC OS tool to talk to the OpenBSD sysctl handler. Whether the OpenBSD handler will talk to the new ROOL tool is something I haven’t tested.

With a bit of saucy source abuse the ROD sysctl does build.

--- Inet6.InetRes.sysctl.c.SysCtl_00	2022-12-28 07:31:15.0 +0000
+++ Inet6.InetRes.sysctl.c.SysCtl	2022-12-28 07:31:15.0 +0000
@@ -228,3 +228,3 @@
                                 break;
-                        case CTLTYPE_QUAD:
+                        case CTLTYPE_S64:
 #ifdef __riscos

For some reason the built binary is called osysctl.

For some reason the built binary is called osysctl.

As opposed to o.sysctl ?

How does a machine with the ROD stack find its own IPv6 address? Is there a “proper” method, perhaps using the Socket_ SWIs, rather than trying to parse the output of ifconfig?

For IPv4, there’s a system variable. There isn’t for IPv6. (Yet.)

It doesn’t help that *ifconfig doesn’t seem to allow its output to be redirected. Nor does *Spool seem to catch its output.

One for Gerf – any chance of a updated version of your Easy socket module – to make programming over the Internet err easier :-)

+1 for an updated Easy Sockets module!

Hi
A couple of comments about building the OBSD stack. Firstly Thanks Theo for your feedback.
FWIW the sysctl sources as we use them are in the InetRes folder.

The releases are built using the buildall script in the build folder.
3 flavours are built. Using a standard iMx6 build… as far as the export libraries and resources stage. For the IOMD and v5 variants I use the same start point and define machine IOMD for the IOMD build, and ARM11ZF machine for the v5 build. (I thus have 3 library sets. New-iMx-v6 (standard), New-iMx-v5 for the Arm11 build and New-iMx-IOMD for the IOMD build)
The BuildAll script sorts the required directories in the deploy folder.

The issue with sysctl reflects a recent renaming of type _QUAD to _S64. We provide sysctl for the (relatively) few occasions when that interface is used. Since sysctl at the point we needed it did what we needed we didn’t ‘do our own’. The version currently in the stack hails from a point in mid 2020. As a build issue it hasn’t yet impacted here… the most recent resync of build tree was early Dec I think. I’ll keep my eyes openfor this though.

As for ‘will it work on the new ROOL sysctl’ … yet to be sorted, if needed. In the standard installation of the ROD stack, the only sysctl generally accessible is (at least should be) the one supplied in the distribution.

With help from Rob Heaton, I’ve demonstrated an IPv6 server socket on RISC OS. It shows that the principle works.

Something else to point out is that GCCSDK defines AF_INET6 as 26 instead of 28 or 24, and since I can’t find any obvious signs of unsupported values being filtered out or remapped before calling the socket SWIs, it seems likely that there are already RISC OS applications out there calling the SWIs with GCCSDK values, especially if they use cross-platform libraries like curl for internet access.

I don’t think that’s so much of a problem. If any preexisting apps try to use socket type 26, they will fail on all the stacks. That means they’ll carry on as IPv4 only, but they should still work. If the app was using 24 it might try to use the ROD stack but crash because the struct layout or other fields mismatch (since whatever struct layout GCC’s Unixlib uses could not predict what ROD would do in the future; Unixlib had to invent some code for this years ago just to make things compile, even if they would never succeed. It tends to borrow from glibc which means there’s a high chance of mismatch with OpenBSD).

It does underline the point though that there needs to be a stable ABI, because the ABI gets baked into things that aren’t TCPIPLibs. So tweaking TCPIPLibs to match the IP stack isn’t the end of the story, it needs to be tweaked in Unixlib and other places as well.

(Confusingly ROOL have a different library called UnixLib that’s often linked together with TCPIPLibs. I’m not referring to that one)

How does a machine with the ROD stack find its own IPv6 address? Is there a “proper” method, perhaps using the Socket_ SWIs, rather than trying to parse the output of ifconfig?

You read the IP address of the system in exactly the same way for IPv6 as you do for IPv4. That’s the proper way to do it.

• IOCTL_SIOCGIFADDR is the ioctl call to use to read the address of a specific interface. (IOCTL_SIOCGIFADDR = 0xc0206963)
• IOCTL_SIOCGIFCONF is the ioctl call to use to read all the interfaces that are available. (IOCTL_SIOCOGIFCONF = 0xc0086914)

This mechanism hasn’t changed, although you cannot use the Internet 4 compatibility version of the system call because it isn’t large enough to read the data. Basically, any code that was written for RISC OS to read IP addresses in the past will be able to read the IPv6 data. The only difference is that your SIOCGIFCONF will…

a) return more data than you are expecting, so you might need a larger buffer (but this would have also failed on older Internet stacks anyhow)
b) return with fields that you don’t understand such as the AF_INET6 field or others (but again, this could have happened on the older Internet stacks as well – it’s just part of the API).

If you don’t handle the larger buffer size, you’ll miss interfaces.

There are more addresses per interface, so this might confuse you but you should pre-populate the address with the result from the SIOCGIFCONF, and this will give the stack sufficient information to identify which interface you are requesting the address of when you call SIOCGIFADDR.

You can find example code which handles reading the interface from the system in my riscos-examples repository:

https://github.com/gerph/riscos-examples/tree/master/networking/sockets

Edit: Ah-ha, I’ve found it. Back in July last year, I apparently updated my SetInetVars to add support for IPv6 – https://gitlab.gerph.org/-/snippets/28. This is a really ugly BASIC program which will set a whole bunch of variables based on the interfaces and addresses that are present. It was something I wrote back for the days of the Freenet stack, when there were a bunch of stacks and dialers that would set up different addresses and things were not standardised. This was before having multiple addresses on interfaces was common.

In these more enlightened times, I’d really not recommend relying on a system variable like this as it’s likely to go out of date. This is particularly the case for automatic address selection for IPv6. If you really need to know your IP address (and remember that any given interface can have multiple addressses, and you can have a multitude of interfaces on your machine).

Here’s the sort of output from the tool on my MacBook:

charles@phonewave ~/projects/RO/pyromaniac (analogdevices-experiment)$ pyrodev --common --command SetInetVars --command 'show Inet*'
Program renumbered
Inet$awdl0$IP6 : FE80:0:0:0:B07A:D1FF:FEB1:160
Inet$en0$Broadcast : 192.168.0.255
Inet$en0$Domain : gerph.org
Inet$en0$HostName : phonewave
Inet$en0$IP : 192.168.0.98
Inet$en0$IP6 : FE80:0:0:0:18E7:7BF3:B357:167B
Inet$EtherDomain : gerph.org
Inet$EtherHostName : phonewave
Inet$EtherIP : 192.168.0.98
Inet$EtherIPAddr : 192.168.0.98
Inet$Hostname : localhost
Inet$llw0$IP6 : FE80:0:0:0:B07A:D1FF:FEB1:160
Inet$lo0$HostName : localhost
Inet$lo0$IP : 127.0.0.1
Inet$lo0$IP6 : 0:0:0:0:0:0:0:1
Inet$lo0$RemoteIP : 127.0.0.1
Inet$LocalAddr : 0100007F
Inet$LocalHostName : localhost
Inet$LocalIP : 127.0.0.1
Inet$LocalIP6 : 0:0:0:0:0:0:0:1
Inet$LocalIPAddr : 127.0.0.1
Inet$LocalIPRemoteAddr : 127.0.0.1
Inet$utun0$IP6 : FE80:0:0:0:A64F:D13B:55E7:C5E6
Inet$utun1$IP6 : FE80:0:0:0:5125:467:E785:732F

One for Gerf – any chance of a updated version of your Easy socket module – to make programming over the Internet err easier :-)

If I were to update the module, I’d probably re-write it in C. Probably. It’s not a very complex module, but it would become a bit harder if I had to handle the site address resolution properly (which it doesn’t at the moment). So ‘maybe’ is about as far as I’d commit to. I’m still trying to write up some words on what I did last year on Pyromaniac and it’s taken me way longer than I intended, but I might look at that when I’m done. No promises, though.

I have noticed that the ROD stack I not listed anymore on the ROD website (in Projects). Does anyone know the reason?

It’s not listed in the “Projects” dropdown on the front page, but if you go to the Projects page it’s still there.

I have noticed that the ROD stack I not listed anymore on the ROD website (in Projects). Does anyone know the reason?

If you scroll down the projects page it is still there as it always has been. Just click on Projects and ignore the drop down menu. Remember Pinbaord 2 is now no longer in beta its in general release while the TCP/IP stack is still offically a beta and open source…..

Remember Pinbaord 2 is now no longer in beta its in general release

Since general release would involve it moving into the standard OS release, as per the description by Andrew R. of the outline for its development, I’d say limited release pending move to general release.

Since general release would involve it moving into the standard OS release, as per the description by Andrew R. of the outline for its development, I’d say limited release pending move to general release.

I think you have your definitions backwards. A general release is available to the general public. Whether it is built into the OS release is entirely distinct from whether it is available to the general public. The product is available to all on their website, so it is not a limited release – you are not restricted in your ability to obtain and use it.

A general release is available to the general public.

+1

The stack is available to everyone.

If users require a pre-configured distribution where it is already integrated and tested, then probably the best candidate at this point is RISC OS Direct? Up to ROD tbh.

Is the lan from the Raspberry Pi 3b+ supported or not? Because it did not work with this TCP/IP stack.

100Mbit USB ethernet based devices such as
. Beagleboard
. Pandaboard
. Earlier Pi models 1 – 3
. Pi zero (w) with USB ethernet adapter

Micky

Is the lan from the Raspberry Pi 3b+ supported or not? Because it did not work with this TCP/IP stack.

Check your configuration, because it works.

Both of the Pi’s that I use have the ROD stack installed. This, an original ARMv7 Pi 2, and the 3B+ in the bedroom.

Earlier Pi models 1 – 3

I think that rather than saying “3 but not 3B+” it means “not four (or later)” because the Pi 4 uses a different network chip, and the Pi 5 is… academic and not worth mentioning further.

Ok, thanks!

I test all combinations of configure. But interfaces status shows always:

Activity at 100Mbps

OK and polarity are working.
Full duplex and active did not work.

Micky

I have a 3B+, and the ROD stack didn’t work reliably for me – it often would not start up the LAN interface. I think one other person also reported this. I also had other problems that seem to be specific to my setup here. Eventually I uninstalled it.

I really must give it another go.

Micky, if you have trouble, please do all you can, and get all the help you can, to diagnose the problem; and report any problem via the proper bug tracker.

Just because I had problems, doesn’t mean you will have the same.

Where can I find the bug tracker?

Micky

To quote from the web site that the ROD stack is downloaded from

"A ticket system (powered by RISC OS, running on the new stack) is provided for feedback and support.

Details are included in the zip."