ROD's new TCP/IP stack.

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.

Well, at least the issue doesn’t appear to be in a critical part of the stack, so testing of other aspects and the stack generally can continue with IPv6 off.

The way it has been described to me is that IPv6 regularly changes its address (by design) because that’s how the underlying protocols work. It would appear that freeway (?) responds to address changes by reiniting shareFS, hence the dropouts. Now, since ShareFS is only an IPv4 protocol and not an IPv6 protocol, changes in the IPv6 space shouldn’t affect it. But they do, so that needs sorting.

Of course, there may be more to it than this, but that’s where the clues have led us thus far :)

Isn’t the change interval supposed to be measured in hours, not seconds?

The messages are sent repeatedly, which I suppose is what we should expect. I haven’t yet worked out which of my network entities is sending them. The RO stack responds rather crudely by assuming an address change and sending round a Service Call to say the IP address has changed, which makes ShareFS re-establish its connections.

The simplest solution is to replace the service call with one that says the IPv6 address has changed, which will leave ShareFS unaffected.

Even that solution may have to be a bit more subtle, because the IPv6 address is not actually changing in almost all cases.

Isn’t the change interval supposed to be measured in hours, not seconds?

Hours, days, “depends”¹, but as you will note not only does that vary, but the local router puts out regular (200 seconds-ish) advertisements. Those shouldn’t disrupt the client devices though.

¹ Server/Router dependent, see the ref. page.

I haven’t yet worked out which of my network entities is sending them.

Wireshark is your friend, and I think you will find it’s the router which also acting as your local DHCP server.

Wireshark is your friend

Wireshark certainly is my friend. (A previous boss decribed me as a Wireshark ninja.)

It’s Wireshark that captured these packets for me, and tcpreplay that confimed that resending them caused the symptoms.

However, my router (BT Smarthub) is very unfriendly at letting me know which IPv6 address is associated with which device – especially the local ones. I have to work my way through the MAC addresses.

Don’t forget, DHCP doesn’t apply to IPv6 (it’s SLAAC), and the Smarthub doesn’t appear to offer DNS for IPv6 addresses.

However, my router (BT Smarthub) is very unfriendly

Sounds like your SmartHub is running the same lame firmware as my Livebox.

It won’t tell me the IPv6 address if there’s an IPv4 one, and likewise there’s no IPv6 DNS. The client has to use IPv4 to read the AAAA record to then switch to IPv6.

but the local router puts out regular (200 seconds-ish) advertisements

That might be a factor, as it seems that while ShareFS was irregular and sort of vanished with quite some gusto (at one time it failed to stay alive for more than a few seconds), when it did work it never managed more than a couple of minutes. So I’m guessing perhaps these adverts were triggering something, and the times it would lose the plot completely could have been other devices answering?

Whatever, I can confirm on my Pi2 that disabling IPv6 and ShareFS “mostly behaves”…

…does anybody know why the hourglass goes red and it slowly counts down before erroring out, only to work upon retrying the action? Shame it doesn’t bother to respond to the Escape key to mean “give up now, user is impatient”.

There are two devices generating the Multicast Listener Report V2 messages on my LAN: my Linux box, and the OpenMediaVault server (a RasPi 3B+).

However, my router (BT Smarthub) is very unfriendly at letting me know which IPv6 address is associated with which device – especially the local ones. I have to work my way through the MAC addresses.

Don’t forget, DHCP doesn’t apply to IPv6 (it’s SLAAC), and the Smarthub doesn’t appear to offer DNS for IPv6 addresses.

Sounds like expected behaviour for Stateless Address Auto-Configuration – skim down to: What is SLAAC? where it says:

“SLAAC stands for Stateless Address Autoconfiguration and the name pretty much explains what it does. It is a mechanism that enables each host on the network to auto-configure a unique IPv6 address without any device keeping track of which address is assigned to which node.”

You might be better off firing up an IPv6 DHCP/DNS on one of the boxes – I think DNSMasq on the OMV should do it. (No experience of OMV, I have an old Sophos SG125 with OPNSense installed¹ that I’m playing with)

Edit
Digging around a little, someone has done some ARM compatible builds of OPNSense – listed here

¹ Left behind by a third party because the PSU had a fault. I fix things, it’s fixed. Ideally, needs a wireless NIC adding, so the household net has a better base.

There’s now a beta which we hope will resolve the sharefs issue. If you’re affected and would like to test, please drop Andrew an email over the weekend and he’ll send you a copy once he’s back in action after the show next week.

I can report that this fixes the ShareFS issue for me. The description I have been given, of cause and effect, makes me believe that it should fix if for everyone.

Should we look toward a bug fix description in due course?

Is anyone still having a problem with the new ROD TCP/IP stack, or has anyone given up completely on it?

I’ve got more good news.

I’ve been sent another release candidate, which appears to work perfectly well.

The most annoying problem has been failure to start up the EtherUSB driver on my RasPi 3B+, which has an SMSC78XX network chip. John Ballance suggested that I try putting a *RmReinit EtherUSB command in PreDesk. Having done that, 20 out of 20 starts (15 power cycles, 5 not) all came up correctly.

So it’s going to remain as my normal TCP/IP stack. ShareFS shares all remain up; all normal IPv4 activity that I’ve tried works; the limited amout of IPv6 stuff that I’ve tried (plain HTTP client, HTTPS client, plain HTTP server) all work.

The only thing I know that doesn’t work is I can’t use Wiresalmon with it – but that’s an unusual requirement, so I can live with the restriction.

If anyone wants to give it a go, you can ask Andrew Rawnsley for a release candidate. I’m sure he wants more testers.

I’ve been sent another release candidate, which appears to work perfectly well

I’ve done some testing of the updated stack over the past few days, which has resulted in further bugfixes and improvements, with all the systems I have and though I have a 3B I don’t have a a 3B+ so couldn’t confirm if it worked so glad to see you got it working with the same trick that fixes issues with the Beagle/Pandboards via a RestartEJ file that does what you have.

As it has a different network chip to that in the 3B then I guess the stack may not be differentiating it.

I also couldn’t test a couple of the PiB revisions, Pi 1A,1A+, latest Pi400 with changed network chip and Pi Compute module ones..father christmas may resolve the latter :-)

The latest beta stack also works now on the Iyonix as well, at least here it does.

Christmas and the lead up to it is a time of joy , rest and celebrating but John & Andrew haven’t had much of that over the past few days so it a big public thanks to them and ROD for all the efforts on the updated stack.

Forgot to say you could also test the latest EtherUSB
from ROOL, but don’t forget to not mix stacks.

Also why not test the 5.30 stable release candidate
as well.

We may not be able to code much but testing can be fun and helps things move forward.

Also why not test the 5.30 stable release candidate as well.

Still no ROMs included for the most relevant platforms like all Pi variants, Ti, OMAP5, ARMX6, mini.m.

Still no ROMs included for the most relevant platforms like all Pi variants, Ti, OMAP5, ARMX6, mini.m.

Are we at risk of ‘perfect being the enemy of good’ here? Would a 5.30 RC built against RC4 commit on those platforms perform noticeably less well than 5.28? Or contain real show-stopper bugs that weren’t in 5.28?

Are we at risk of ‘perfect being the enemy of good’ here?

Possibly. Close to home for me, a project team (all non-techie) withheld info about their project. What leaked was enough info for us to figure out what a cluster it was going to be.
They cancelled the go-live when stuff they thought would work, failed abysmally in the “rehearsal” Loop round go again, still no sign of engagement with the techies. Sigh.

Would a 5.30 RC built against RC4 commit on those platforms perform less well than 5.28? Or contain real show-stopper bugs that weren’t in 5.28?

Given that a lot of people who are likely to read this are quite adept at diagnosing problems and finding the fix or a repro for the bug, I would suggest that allowing copies out to test would be a better idea than not.
Whatever.

I have a 3B I don’t have a a 3B+ so couldn’t confirm if it worked

The 3B+ does have a different LAN chip to the 3B.

I also couldn’t test a couple of the PiB revisions, Pi 1A,1A+

Do you mean the ‘A’ variant which doesn’t have Ethernet or the original Pi model B (256MB and 512MB variants) and the B+ which all have the same LAN chip?

There were some minor revisions of the 1B, memory size and number of USB ports and yes the A series has no ethernet and I would of tested them the same as the Pi Zero with a USB to Ethernet adaptor.

Logically you may say well there wasn’t much difference but you never know.

Thats why the more people test, like Dave covering off my lack of ability to test the 3B+, which I did say had a different Ethernet/Lan chip, was good as it captured another system where the EtherUSB module needed a bit of a kick to get going.

I also missed the Pi Zero 2 off my list that I was unable to test.

Assumptions always have a habit of coming back and biting you.

Loop round go again, still no sign of engagement with the techies.

Sounds like your average government IT contract. Do a good job… actually you don’t have to do a good job, screw it up and go twice over budget and eventually deliver something that isn’t capable of running without 24 hour life support… you’ll still be paid handsomely. “SAP ERP” are letters that when you see them in The Register, you know it’s going to be a cluster before it’s even been born. Case in point: https://www.theregister.com/2023/12/19/uk_tax_collect_launches_500/ and, of course, far too many “let’s digitise the NHS” projects, that usually means “fark all benefit to the patients, pain in the arse for the staff, but throws everything to private healthcare providers in the US so we get nice brown envelopes for your troubles”.

The 3B+ does have a different LAN chip to the 3B.

To put a name to it, the older four USB models with 100Mbit networking used an SMSC LAN9514.
The original two port 1B used an SMSC LAN9512.

The 3B+ with gigabit networking uses a Microchip LAN7515, but note that it has to punt that through the USB 2.0 connection to the SoC so it’s more like 300Mbit networking (assuming nothing else is using the USB port at the same time).

“let’s digitise the NHS” projects, that usually means “fark all benefit to the patients, pain in the arse for the staff, but throws everything to private healthcare providers in the US so we get nice brown envelopes for your troubles”.

Um.

This post is liable to disappear or be heavily edited if/when things go wrong…

For the moment, a noddy HTML page is being served up at http://raspi-davidhigton.dynv6.net from my RasPi running the new ROD stack and a recent RO5.29 release, when the machine is on (during most of each evening).