TCP/IP stack: A second great networking opportunity

There is more, and we may actually do some practical example specific for RISC OS or some tutorial. I am quite busy at the moment, but if no one has time to do it, I’ll add it to me TO DO list of posts to write for RISC OS on my blog.

As you obviously understand all the SWIs, do you think you could also document them on the Wiki for everyone as well?

Is it just the SWIs Socket_Accept, Recvfrom, Recvmsg, Sendmsg, Getpeername and Getsockname that are the ‘old Internet 4’ SWIs?
These match the ones listed as being emulated in the Technical Note. They are documented in PRM 5a, as supplied with the DDE, but not in the ROOL Wiki.

Are the only ‘new Internet 5’ SWIs the same six names with a suffix of ‘_1’ ? I have not been able to find any reference to these in any RISC OS documentation, even though they have apparently been available since RO3.7 in 1996.

Each SWI is the implementation of one of the Socklib functions. Those 5 SWIs are the only ones where the parameters to the functions are different between Internet 4 (BSD 4.3) and Internet 5 (BSD 4.4). For example, if you want to call accept() with BSD 4.3 parameters you use Socket_Accept and if you want to call it with BSD 4.4 parameters you use Socket_Accept_1. When compiling a C program, what happens is that when COMPAT_INET4 is defined accept() maps to Socket_Accept and when it is not defined it maps to Socket_Accept_1.

The important thing to realise about the change that’s currently underway is that it’s not stopping programs that were built for Internet 4 running, but it means that in future you won’t be able to build new programs that target Internet 4, because COMPAT_INET4 will no longer exist. However since Internet 4 is long since obsolete (since RISC OS 3.7) that shouldn’t really matter to anyone.

In case, like me, you don’t read csa… you might find this article on Riscository very interesting.

“Machine startup has not completed succssfully: ‘Bad alignment request’”

Edit: and it looks like I’ve got an IPv6 address, but not an IPv4.

Oh how I wish I’d backed up !Boot first (I would certainly advise everyone else to do so). Installed the new update and got a hang on boot. Uninstalled it again and I have no Internet connection.

Will update once I’ve got it working again…

Edit: Assistance required. Configure/Network has no ‘light’ under Internet and when I go in there it’s like it’s never been set up. I can enable the interface, turn on DHCP, and set a hostname, then when I click on Save I get:

Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1822D4, pc = 00000000: registers at 00017F20

If I try again without rebooting then I get a “file in use” message.

I’ve deleted Choices.Internet and have replaced the !Internet app with a fresh copy from 5.28 and rebooted, but I get the same error when trying to save the settings. While I don’t think this error is technically related to the new stack (since I’ve uninstalled it), can anyone advise what might be going wrong here?

Edit 2: Fixed for now. I renamed !Boot then installed a fresh copy from 5.28, rebooted and configured everything. Then I copied Choices.Internet and Choices.Boot.PreDesk.SetupNet to the old !Boot and renamed it back again. This has restored the network connection but hasn’t fixed the crash shown above; when I click Save under Configure/Network it wipes the SetupNet and Startup files then gives that error. I’m not going to touch the new stack again until I’ve figured out what’s causing that.

Edit 3: It appears that the new stack includes a new InetSetup plugin which crashes when used with the old stack. The uninstaller didn’t roll back InetSetup so I had to extract that from the 5.28 image manually. That’s fixed the crash on save.

Now to write all this up in the ticket system…

Related to Chris’s comment I created a backup of the !Boot before installing and also read the “Read Me First” (downloaded an up-to-date !Omni). Then installed the new stack and after a quick reboot the new stack is working – can connect to my NAS using the new !Omni [haven’t tried the old one yet].

After some more experimenting I managed to get an IPv6 address as well and could ping6 to ipv6.google.com – so this really looks like a step forward now.

And this is on a relative old RISC OS (5.24) but it all seems working fine.

(One other note, shouldn’t we discuss the details elsewhere in General or Community Support instead of here?)

I hope anyone having issues is logging them via the Bug ticketing system they provide details of in the Zip file.

Have you all got thr latest !Omni installed ? per the read me first file.

Firstly thanks to all who are trying out the new stack. Hope you enjoy it.

For those who have problems, please do submit a ticket. All being well one of us (either Richard/Andrew or one of the devs) will be in touch with you next week to get you sorted (or to track down the problem).

Since the stack has been fairly widely beta tested, we’re a little bit surprised to hear things like the uninstall bug, as it was always intended that any changes would be fully reversible (the old !InetSetup is backed up during installation). Expect a fairly rapid response on that after the Bank Holiday weekend.

It seems that the uninstaller failed to delete !OBSD and then didn’t get any further. I’ve put some details in my ticket.

As for this:

Installed the new update and got a hang on boot.

I’m not actually convinced that it’s an error, per se. I realised while poking around in !OBSD that there are new modules for EtherGENET, EtherUSB, etc. Notably there isn’t one for EtherWILC… so I’ve concluded that I’m actually running on an unsupported hardware configuration. Note that the text in the “Features” file lists the supported computers but it seems that the individual interfaces need to be supported too, which wasn’t originally clear to me.

A question: The docs say that the new Resolver and MbufManager can be used with the old stack. There are two versions of each. Do I want the “v5” or “non-v5” versions? What’s the difference? I’m assuming I want v5 because I’m on RISC OS 5, but I could be on the wrong track!

I’m assuming I want v5 because I’m on RISC OS 5

From what I can see, that is wrong. I think that v5 is only used on old processors that do not have (DMB & LDR/STR/CLR)EX instructions. The code following is based on what is used in Install:

   bits%= ((1<<8)+(1<<5))
   SYS"XOS_PlatformFeatures",34,-1 TO r0%, , , ,r4%
   EarlyMachine%= r0% AND r4% AND bits%
   IFEarlyMachine%<>bits%THEN PRINT "Use v5" ELSE PRINT "Do not use v5"

Just to add, v7.00 is running happily here on my Titanium and RPI3B.

From what I can see, that is wrong. I think that v5 is only used on old processors that do not have (DMB & LDR/STR/CLR)EX instructions.

Aha, so v5 is for Armv5 processors. I’m glad I asked :)

Thanks!

Just to add, v7.00 is running happily here on my Titanium and RPI3B.

I think that is worth a +1.

v7.00 is running here on the Titanium, RPi4 and RPi400.

IPv6 is not a thing yet in the Plusnet world, but being able to unthrottle the Titanium’s networking is the benefit. Installing and uninstalling v7.00 has been seemless, and there have been a few while checking LAN protocols. Even ShareFS has caused no grief.

we’re a little bit surprised to hear things like the uninstall bug

Maybe it was good enough that nobody saw the need to uninstall? ;)

and RPI3B.

Pi 3B+ here, has been running awhile, and improving with each release.

IPv6 is not a thing yet in the Plusnet world,

I’ve not bothered yet as I use static IP for IPv4. Not sure how one would go about doing such a thing with IPv6.

[reason: Pi boots in about ten seconds, the router takes several minutes, traditionally DHCP happened once at boot so dynamic IP is useless for bringing up the machine from a power cut]

Even ShareFS has caused no grief.

Sitting outside using the old Pi1 (old stack, RISC OS 5.23, it’s my SD card from ~2016!). It’s a real boon to have ShareFS to have access to the filing system of the Pi3 (in the bedroom) in a way that is RISC OS friendly.

It’s a little slow at times. I’m not sure if this is due to ShareFSWindow (set to 2) or if it’s just the shock of the blatant and massive difference between the Pi1 and the Pi3 (it’s like going from a RiscPC to an A310), but “it works” so I’m not going to fiddle.

I should add – what I especially like about this new network stack is the general compatibility. You install it, check it’s working as expected, and then just forget about it. Existing software continues working. No new libraries, nothing needed rebuilt. I don’t use Omni so I don’t know what’s with that…but LanMan98 and WebJames and NetSurf and ShareFS and Manga and FTPc (etc etc) didn’t notice the change. Which is how it should be. :-)

ShareFSWindow

A particularly brief testing session indicates that ShareFSWindow is not noticeably important now, try your luck with 10, that gave similar speeds as 2 did. The fiddling with ShareFSWindow values that kept us so entertained for so many years may no longer be required. There has been no sign of the evil read hourglass. To be fair this is with similar machines on the LAN, Titanium, RPi4 and Rpi400, it might be a different story if RiscPC had to be accommodated.

Wouldn’t it just be so nice, a ShareFS that ‘just works’.

ShareFS is slow, but it always was.

Anyway, early days …

on: Pi boots in about ten seconds, the router takes several minutes, traditionally DHCP happened once at boot so dynamic IP is useless for bringing up the machine from a power cut]

I thought the new stack setup had a dynamic IP pickup – i.e. not simply at boot – and thus people in your situation had an automated “recovery”
If that dynamic pickup/recovery is a feature, then you’d be a prime candidate for testing that specific aspect.

Maybe it was good enough that nobody saw the need to uninstall? ;)

Well I did install/uninstall/install on:

Imx6
Pi1
Pi2
Pi3
Pi4
Beagleboatd
Panda board

And it worked everytime on later beta versions, though it did fail on some of the earlier ones.

The only other time was when I tried it on an unsupported system and had some issues.

Once on it though I can’t see a reason to go back :-)

NB For some reason my longstanding account has gone AWOL so hence new account number

shouldn’t we discuss the details elsewhere in General or Community Support instead of here?

Quite right. Having discovered an entertaining foible I will start a new topic.

Hi

Firstly. We ONLY have drivers for EtherTH (iMx), EtherUSB(various), EtherGENET(Pi4), and EtherCPSW (Titanium).

NO Other drivers will work as the new stack needs additional capabilities NOT built into the older drivers.

Please do NOT try the stack where an unsupported interface is in use. I understand there is a WiFi hat which uses a driver we haven’t encountered in testing. Obviously it doesnt’t work!.

There is a ticket system… see install instructions… where help can be sought.

Emergency get out of trouble instructions follow in the next post.

‘GET OUT OF TROUBLE’
In the unlikely event that install fails, and you cannot revert using the uninstall feature then this is what you’ll need to do.
1: delete !!ip6.net
2: delete !Boot.Choices.Internet.Startup
3: In !Boot.Utils you should see oldBootRun. IF you do, then delete the BootRun file and rename oldBootRun→BootRun
4: likewise, in !Boot.Resources.Configure you should see old!InetSetup. IF you do, then delete !InetSetup and rename old!InetSetup→!InetSetup.

5: Reboot the machine. You’ll have no internet, so several complaints through startup.

6: type *unplug, and then do rmreinit for each of the network modules shown as unplugged. As a minimum, MBufManager, Internet, DHCP, and Resolver.

7: reboot the machine again

8: double click !Boot and run the Network configuration tool. Configure as you want and let the machine reboot when it asks.

9: All should now be OK. If not, did you rmreinit the correct Ether driver (e.g. EtherTH if iMx)?

If this still fails then please resort the the ticket system to report the issue and seek help.

For those who wonder, the installer contains 2 builds of the stack. The v5 version is for ARMv5 machines, e.g. Pi1, and the normal versions are for the more recent machines. I would expect the v5 versions to function on later machines, possibly slower, but attempting to run the non v5 version on earlier machines WILL create data aborts.

The installer will correctly decide which flavour to install, on a machine by machine basis. Copying the !OBSD app betweem machines may leave you with an inappropriate installation.

I understand there is a WiFi hat which uses a driver we haven’t encountered in testing. Obviously it doesnt’t work!.

It’s obvious when you know that the new stack uses new drivers. I assumed that the drivers were at a lower level than the protocols in use and didn’t realise that new ones were required/supplied.

I’ll have to re-test install/uninstall and see whether I get the same behaviour a second time… and then try it again with the HAT removed. In any case I’ll update my ticket.

I’ll have to re-test install/uninstall and see whether I get the same behaviour a second time

I have now noticed corruption of the disc map. This was likely already present before I even downloaded the new stack, so at this stage I’d place any blame on the failed uninstall squarely at the corrupted map rather than the uninstaller! Sorry for the red herring, as it were.