ROD's new TCP/IP stack.

I assume it’s not BT

Ironically it is Plusnet … owned by BT!

But my router does support IPv6, so if there are exact details of what ifconfig to use, I can try.

If you’ve got a decent router you can setup an IPv6 over IPv4 tunnel, which will allow you to do IPv6 testing to the internet, even if your ISP doesn’t support it.

Interesting that Druck was asking about this problem in 2020 in Plusnet help group -(no IPv6 with plusnet)

But my router does support IPv6, so if there are exact details of what ifconfig to use, I can try.

There are clear instructions in the archive. As for enabling SLAAC in the router, if it isn’t already, you’ll have to look through your router’s web pages.

Well, I think I have done as Dave suggested:
Router now set to accept IPv6, tunnelled over IPv4.
RPi3B running RO5.28 (19 Oct 2020)
Did SLAAC_Start etc
*ifconfig -a now shows 3 ipv6 lines under ej0.
Start Zap v1.48 (12 Jul 2015) tnk-11
Open Zap TaskWindow
*ping bbc.co.uk runs as normal
*ping6 bbc.co.uk warns about multiple addresses, uses v6 addr
but no other output until Escape pressed.
Close TaskWindow and all is well.

Note that ping6 behaves exactly the same from a real command line on the RPi3B, and on my Titanium in a StrongEd TaskWindow. Has ping6 ever been seen to work?

Has ping6 ever been seen to work?

As you can see from a little way back in this thread, it worked for me.

It took a couple of minutes from issuing SLAAC_Start to receiving a non-local IPv6 address.

If your ISP doesn’t support IPv6, you may only be able to ping6 addresses on your LAN.

If your ISP doesn’t support IPv6

It’s not always as simple as that. Orange France “supports” IPv6, I see a long but if gibberish when I go to my blog (it shows the IP address at the top right).
But online IPv6 tests are not all successful.

As far as I can work out (though I’ve not looked too deeply), the underlying IPv6 is supported, but you need to do IPv4 DNS lookups to get the AAAA record to know which IPv6 address to connect to.
So… It mostly works but not completely. Luckily this stuff is handled in the background so it appears to work, which is probably good enough for most users.

No idea if the Livebox supports SLAAC. I would imagine so as the printers and phones get IPv6 addresses, but as far as the user is concerned, the only option is IPv6 On/Off.

I suppose I should fiddle with the stack to enable it and see what happens. ;)
Does anything (Iris?) currently support IPv6?

I was just about to give up having convincingly proved that my router was not playing with SLAAC. However a little digging in the SLAAC doc found the answer.

ifconfig ecp0 inet6 autoconf enabled IPv6 on the Titanium, and similarly on the RPi400.

ping6 doesn’t seem to do much from the Mac or Linux here.

I am not sure that IPv6 is actually doing anything much on Plusnet. Tunnel to nowhere?

The router is a TP-Link Archer VR900.

(A prod around the internet suggests that Plusnet “hope” to introduce FTTP and IPv6 this year.)

What is the best way to obtain a complete build with the new stack?

Direct?, 4.29?, wait fot 4,30?

*ifconfig -a now shows 3 ipv6 lines under ej0.

Martin, did you get a line that began something like:

inet6 2a00:23c7: (etc)?

To be useful, the address would have to begin with something other than ::1 or fe80:

The delay from issuing SLAAC_Start to getting a non-local IPv6 address has, for me, been very variable: from almost nothing to several minutes (long enough for me to think it wasn’t working).

Did some ping6 tests on my Pi3 (OS 5.29 24-Nov-20) in a Zap TaskWindow and I usually get:
ping6: sendmsg: No route to host

but for:
ping6 riscosopen.org
ping6: memory allocation failure

No hourglass or lockup here.

Edit: note that yesterday when I was playing around with various applications (internet radios in DigitalCD, FTPc, LanMan98FS, LanManFS, NetSurf) at some point the Hourglass was appearing from time to time for 5 to 10 seconds. I still could work (for example drag windows) while the hourglass was enabled.
I just don’t know what application was triggering it.

The new stack can be downloaded from https://www.riscosdev.com/ by visiting the Projects page. People report it working on versions of RISC OS 5 back to 5.24, although it has primarily been tested on 5.28+

Remember that if you see unexpected things, or feel you may have found a bug, please use the ticketing system described in the documentation in the download. The programmers do not continually monitor these forums (as a rule of thumb) whereas they do read the tickets regularly (and reply, where practical).

Thanks all, and enjoy… there’s more good things to come :)

Re: The uninstaller not working properly (posted in the other thread), I tried it again and got slightly different behaviour: This time the OBSD app was deleted successfully but InetSetup and BootRun were not rolled back.

I’m wondering whether this may be related to the reboot that occurs immediately after the files are deleted. In both cases I had quit all apps before running the installer, so shutdown is effectively instantaneous. I know that some drives are infamous for not actually writing data to the physical storage immediately, and I’m wondering whether it’s possible that the Pi is cutting power to the USB SSD before the writes have been committed. Does that sound possible or am I likely to be on the wrong track?

(Note: *CheckMap is not currently reporting any errors)

Re: Zap task window issue. Following the installation of the new stack, I did a quick ping using a Zap task window, and I didn’t notice anything adverse. I’ve rechecked, and all is good (Pi4, build 30-Apr). I also tried the ping6, no effect on a Zap task window. Also, Nettle, Pluto, Newshound and Iris work; everything feels quicker. Thank you, ROD and also the commercial sponsor :)

@Dave

Martin, did you get a line that began something like: inet6 2a00:23c7: (etc)?

Yes, my 3 lines were

inet6 fe80::72b3:***%ecp0 prefixlen 64 scopeid 0x2
inet6 2002:545c:a99:*** prefixlen 64 autoconf pltime 3443 vltime 7043
inet6 2002:545c:a99:*** prefixlen 64 autoconf autoconfprivacy pltime 3443 vltime 7043

@Chris

I’m wondering whether it’s possible that the Pi is cutting power to the USB SSD before the writes have been committed.

I suspect that may well be the case, and I am soon going to update problem 2600119 with my reasoning. [Edit]Now done.

I’m about to test this on my ARMX6. I see in the Readme that I should be running the latest NFS. I don’t use the ROOL NFS, but I do use Sunfish to backup to a NAS box. Has anyone used the new stack with Sunfish? I don’t want to risk breaking my backups if it isn’t a suitable configuration to use with the new stack.

I tested both Sunfish and Moonfish on the new stack and no issues.

Make sure you get the latest versions plus front end updates either via Packman or RISCOSPorts site.

Thanks for the info – it looks like I already have the latest Sunfish components. Just installed the stack. It took two reboots before it was useable – the first ended up at a frozen desktop, but rebooting went fine. I’m just copying off a backup of the pre-install !boot structure before doing some proper testing. I’ll run my usual backup to the NAS (which takes 13m30s-13m50s over the last few nights) to see if there’s any significant difference in times. Playing back a FLAC file in DCD from the NAS over Sunfish was successful, even while backing up !Boot from NAS to NAS via Sunfish at the same time, so bandwidth seems fine.

What is the best way to obtain a complete build with the new stack???

The new stack can be downloaded from https://www.riscosdev.com/

When I was doing some network tests on the new stack I directly connected to my RISC OS Pi 3B and Mini.m via a KVM. Today I accessed them as I usually do, via VNC from a fast Linux laptop. The result was horrendous, it felt slower than the old Iyonix, completely unusable. I ripped out the new stack from both machines, and it’s now back to the slick operation on the Pi4B and the slower but usable speed on the Mini.m

Hence, I wont be using the new stack until there are performance improvements over the existing one. Very disappointing.

My backup test seems roughly equivalent – it went from the usual 13m45s average to 14m03s, which is fair as there were more files to compare than before the update. This is from the second backup run after updating, as there were more files that had changed than usual on the first run. There’s 23GB on the SSD in 8131 folders and almost 133K files that have to be compared across the network to look for changes to copy over.

I suspect that may well be the case, and I am soon going to update problem 2600119 with my reasoning. [Edit]Now done.

Good work. I hadn’t caught that it was doing OS_Reset and I just assumed that it was going through the full shutdown process.

I think we’ve tracked it down: I made a little BASIC program that copies a file with *Copy then immediately does a SYS “OS_Reset”. The resulting file was corrupt.

We’ve all been warned to use an up to date Omni with the new stack. Does anyone know what changes were necessary to make it work?

For me, with the 7.01 stack, I can open an SMB1 share with LanMan, but opening the same share with LanMan98 (which is what I’ve normally done for years) instantly stiffs the RasPi. Is LanMan more recent than LM98, and does LM98 need similar changes done to it?

For me, with the 7.01 stack, I can open an SMB1 share with LanMan, but opening the same share with LanMan98 (which is what I’ve normally done for years) instantly stiffs the RasPi. Is LanMan more recent than LM98, and does LM98 need similar changes done to it?

I have been testing the new stack since the start, and do backups from ARMX6 to NAS using LanMan98 and have never had a problem. Is it specific to the Pi hardware?