ROD's new TCP/IP stack.

Micky, if you could contact us by email – best person is probably andrew at riscosdev.com for this – we’ll send you the latest internal release of the stack, to confirm if you’re still having problems. If so, we’ll pass it up to the programmers for investigation. If you could also include when/where you got your 3B+ (in case there’s been a hardware revision or something) that’d be helpful. I believe it was tested quite extensively on the various Pi models, but it is always possible that different revisions of boards exhibit different quirks that need addressing.

If anyone else has problems with the stack under discussion, PLEASE make sure you’ve reported them completely and correctly in the bug tracker.

Here are the infos:

Hardware: BCM2835
Revision: 2a020d3
Serial: 000000005b866365
Model: Raspberry Pi 3 Model B Plus Rev. 1.3

Code Model Revision SoC RAM Manufacturer
a020d3 3B+ 1.3 BCM2837B0 1GB Sony UK

Micky

Micky, what are the VID (vendor ID) and PID (product ID) of the Ethernet chip in your RasPi? You can find this out at the command line with:

*usbdevices

followed by:

*usbdevinfo n

where n is the device number of the ethernet device that you see in the output from the first command.

Andrew sent me a copy of the latest internal release stack too. It appears to behave just the same as the previous one, i.e. no improvement.

Some questions:

1) Who else sees the Ethernet chip not starting up reliably?

2) Does anyone else see ShareFS shares greying out and being unavailable for 2 seconds a time, more than once a minute? This may be specific to my LAN here; there are several IPv6 devices on it, and I suspect that some IPv6 multicast messages may be triggering it.

3) Having tried to ping6 my own dynamic IPv6 address from various clients, I can see that the address isn’t always up to date – but my Linux box picks up a change very soon after it happens, whereas the RasPi must be using a cached one. Is there a cache in the new stack, and, if so, how can I clear it?

Edit: forget that last question, it’s cached in Resolver, and the only way to make it forget the stale one is to RmReinit it.

Who else sees the Ethernet chip not starting up reliably?

From cold, yes, frequently. This might be related to the NetTime startup failures I’m seeing.
It’s okay from a warm boot, or if I start it up with the reset button held for a couple of seconds.
I have a suspicion that it might be so damn fast (with static IP) that things aren’t quite ready by the time RISC OS is. ;)

Does anyone else see ShareFS shares greying out and being unavailable for 2 seconds a time, more than once a minute?

All the freaking time.
However following the sudden complete failure of SLAAC (kept crashing the machine at boot, usually killing either Pinboard2 and/or Freeway; details posted to the bug tracker), I took the decision to nuke IPv6, and everything has been stable since and my shares have been reliably connected since yesterday afternoon.

What I don’t understand is that the failure is affecting the Pi2, but not the 3B+ (that’s still IPv6 ¹), and it started yesterday and was completely reproducible, yet it worked for a while without problems (like, since July or maybe earlier?).

In case it was something I’m running, I took everything out of PreDesk and Tasks except that which was necessary to start up the stack…and it promptly died all the same.

I can only think that it’s something external that the stack is choking on.

This may be specific to my LAN here; there are several IPv6 devices on it

Expected these days. My phones, the newer security camera (but I’ve disabled the IPv6 port because I don’t know where it’s connecting to and it’s a fixed IP unlike the IPv4 NAT), the printers, etc etc.

and the only way to make it forget the stale one is to RmReinit it.

Doesn’t *ResolverConfig throw away the cache?

¹ I think they’re both running the latest version of the stack, but since there appear to be multiple versions of the SLAAC module with version 7.03 and different sizes/dates, I’m not going to fiddle around with the 3B+. Leave things alone…

Micky, have you tried repeatedly restarting your RasPi? I had no network, but repeated restarts (yes, very tedious, I know!) eventually made it work.

This is the difference between “doesn’t work at all” and “has a startup problem”, and it’s important to know which it is.

Doesn’t *ResolverConfig throw away the cache?

It seems not. I thought it would, too. I tried *resolvercache followed by *resolverconfig followed by *resolvercache, and the stale address was still there. *rmreinit resolver fixed it, though (as it would).

Here are the infos.

Vid: 0424
Pid: 7800

If I start the Pi from cold I must make a reboot to have lan. I use a USB to lan adapter from LogiLink. UA0025C.

With the lan on board from the Pi and Tcpip 703 the Pi restart did not help. I did not use IPv6.

With the Risc OS 5.28 driver for lan I have no lan too. I never have had lan with Risc OS. Only with the LogiLink. UA0025C.

Micky

Andrew has been in touch to say they are looking more closely to find what is malfunctioning.

I took the decision to nuke IPv6, and everything has been stable since and my shares have been reliably connected since yesterday afternoon.

I keep saying this: “Don’t run dual stack on a device, not on RO, not on Windows, not on Linux” Just don’t.

Unless you have a very good reason to do so, don’t run a dual stack.
Nothing wrong with IPv6 in general, nothing wrong with IPv4. Together, they both make demands on the hardware that aren’t good for the other.

It worked fine until it didn’t. The other Pi is still working fine.

All of my Android devices and printers support both IPv4 and IPv6. So I think dual stack is the only way to go at this time, as IPv4 is still very much a thing…

Has anyone tried the stack with Elesar’s WiFi HAT?

I know the readme says it works, but I’m not enthusiastic at trying these things when I have a working system.

I keep saying this: “Don’t run dual stack on a device, not on RO, not on Windows, not on Linux” Just don’t.

Steve, that seems a bizarre thng to say. Presumably Windows runs one; most Linux distributions run one; all routers that support IPv6 run one. No doubt there are many more examples.

Can you justify your recommendation?

How is one to be able to use both IPv6 and IPv4 if not by means of a dual stack?

Has anyone else built any version of the ROD TCP/IP stack from sources? If so, how did you do it?

I have the sources from some time in March. I was unable to build them, but I didn’t persevere as I should have. I want to have another go now, in an attempt to help diagnose the problems that some of us are having. Andrew seems to be happy to give out sources to those of us who are willing and able to help.

Steve, that seems a bizarre thng to say. Presumably Windows runs one; most Linux distributions run one;

Both of those have issues with speed, which can be removed by removing the other stack config. If you want to run pure IPv6, do so. If you want to run pure IPv4 do so. In both cases, you will find the machine is faster running the single stack

all routers that support IPv6 run one.

Ah, now there you hit upon the instance where it might be useful to do dual. People out there are shifting the setup of servers around:

nslookup www.google.co.uk
#################

Non-authoritative answer:
Name: www.google.co.uk
Addresses: 2a00:1450:4009:81d::2003
142.250.179.227

Note that the first alternate is IPv6, that wasn’t the case a few years ago.
Your router will almost certainly have an IPv6 address, if you’re still on BT then definitely (look in the IPv6 WAN config)

Some ISPs were late to even start deploying IPv6 (Orange/France Telecom)

Once all the resources you want to access are IPv6 then you can switch, there are millions of listed IPv6 websites, almost all have an IPv4 address because people don’t want to miss out on customers.

How is one to be able to use both IPv6 and IPv4 if not by means of a dual stack?

Use on your own web visible resources, or use an IPv6 system out there when your computer is IPv4?
Somewhere along the route you need an IPv4/IPv6 proxy like this setup: https://www.arin.net/blog/2020/07/08/how-we-make-ipv6-only-hosting-a-reality/

I’m not a speed freak. Stuff only needs to be fast enough.

I want to move as much as possible to IPv6 because that’s clearly the future. This means I need IPv6 capability.

However, not everything has yet moved to IPv6. This means I need IPv4 capability.

One day it will all have been sorted out, and we will be able to leave IPv4 behind. In the meantime, I’ll be using a dual stack.

Does ShareFS work over IPv6, assuming two RO machines that have IPv6 working?

I’m not a speed freak. Stuff only needs to be fast enough.

Ditto. My Pi can easily outpace my broadband, so it’s of little consequence which protocol is actually in use.

Does ShareFS work over IPv6

Does anything on RISC OS (other than ping6) make any use of IPv6?

One day it will all have been sorted out, and we will be able to leave IPv4 behind.

I doubt it. Far too much legacy stuff around that is IPv4 only and happily living behind a NAT. Like, older things such as the Vonets that pass IPv6 data but are themselves IPv4, or any of the ESP32s (it seems IPv6 will be available in SDK 3 “to come”), older IP/security cameras, any RISC OS machine not running the ROD stack, blah blah.
I don’t think you should put any timescale on the end of IPv4 support. After all, many mobile phone providers use a massive IPv4 NAT in the 10.×.×.x range to provide connectivity to their clients, they aren’t on IPv6 yet; and ISP IPv6 is ‘quirky’. My Livebox supports IPv6, but there’s no IPv6 DNS support. You must use IPv4 to look up AAAA records to then use IPv6.

So, yeah, don’t hold your breath. IPv4 has a good few decades in it yet…

almost all have an IPv4 address because people don’t want to miss out on customers.

Heyrick has both. It wasn’t that hard to set up (but not by me, I should add). The server listens on an IPv4 address/port, and an IPv6 one; and the DNS points to the machine by the appropriate IP address.

Error message:

ifconfig: SIOCAIFADDR: File exits
Press space or click mouse to continue

I have deinstall Tcpip 7.03 because no internet more.

Micky

Is there something new?

Micky

I’ve been talking with John Ballance today. The problem of ShareFS drives becoming unavailable has been reproduced on two other systems, neither of which is a Raspberry Pi 3B – and it happens simultaneously on the systems, which has to be triggered by something coming in from outside.

This does put them in a stronger position to diagnose what’s going wrong.

It would be good to know if these problems go away, on the new stack, if IPv6 is disabled.

More progress. A thoroughly plausible mechanism for the interruptions to ShareFS has been identified. It is caused by some IPv6 Multicast Listener Report messages.

It would be good to know if these problems go away, on the new stack, if IPv6 is disabled.

That appears to be the case, yes.

It is caused by some IPv6 Multicast Listener Report messages.

Is this related to the IPv6 startup crashiness?

Is this related to the IPv6 startup crashiness?

No. That’s a separate problem that I’m going to look at myself.