Public beta of Wifi for ROD TCP/IP stack now live

RISC OS Developments is pleased to announce that the Public Beta of the Wifi and Network Manager components for its TCP/IP stack has now gone live, with testers having access to the software since the beginning of the week.

The Public Beta was announced at the SW Show, and as promised, is now live. If you’d like to join in, simply contact Andrew or Richard at ROD via email, phone or website, and we’ll add you to the list and send you the details to download the software. Source code is supplied on the download site for those interested.

This beta covers platforms using Broadcom chips, which covers the onboard wifi for most Pi devices. Both 2.4 Ghz and 5Ghz wifi bands are supported, as is encryption via the expected modern encryption methods.

The same driver also works on Pinebook Pro, but that beta is being handled separately by R-Comp Interactive, as it requires updated OS builds and other elements specific to that platform.

These last two elements (Wifi and Network Manager) complete the core goals of the ROD TCP/IP stack by providing:

• A modern TCP/IP stack based on OpenBSD known for robust security

• IPv4 and IPv6 support

• Drivers for all current platforms (RISC OS 5)

• Legacy support for older platforms (RiscPC etc)

• Legacy and current software compatibility

• Documentation on many previously undocumented elements and new features

• Wifi support for SDIO-based Broadcom controllers – notably Pi series and Pinebook Pro, with encryption as necessary

• Network Manager to allow flexible configuration, profiles, autodetection and Firewall rules

Coupled with a modern web browser such as Iris, we feel this provides a strong base for modern network/internet on RISC OS computers.

Best wishes to all, and we hope you enjoy the beta :)

To everyone involved, thank you a lot for your hard work!

Has anyone received a copy of this? I requested it via the website soon after the announcement, but haven’t heard back yet.

I’m more interested in the PBP ROM though, as I’m currently adding boot drive creation for the PBP to Partition Manager and would like to work out how to configure the network for WiFi during the drive initialisation.

Please check your email/spam Jon – I’m sure I did send you the details. Please drop me another email (memory aid) and I’ll resend tomorrow.

Has anyone received a copy of this? I requested it via the website soon after the announcement,

My copy arrived via that route the next day.

And, better still, it works.

And, better still, it works.

Has anyone tested the new stack with a wireless keyboard and/or wireless mouse?

Wi-Fi has nothing to do with Wireless things like Keyboards and Mouses. Wireless Mouse and keyboards can already work with things like the Pi.

Much obliged for the correction!

Wireless Mouse and keyboards can already work with things like the Pi.

But a wireless dongle is presumably required?

Yes, the one the devices come with, they do all the wireless and present a USB HID device to the computer.

I suspect George may be thinking of Bluetooth, which is used for some wire-free (since “wireless” is confusing in this context) keyboards/mice. Wire-free keyboards and mice fall into two categories – “ordinary” which come with their own dongle and work just fine because the computer isn’t actually aware of the wireless-ness, and “bluetooth” which don’t come with a dongle (usually) and instead connect to the bluetooth capabilities of the phone/tablet or laptop.

Although bluetooth is often part of the same “technology package” (I’m cautious to say “chip”, but it often is) as wifi, it is a very different set of protocols and is unrelated to networking.

So, right now, no bluetooth. On the flip side, the SDIO work to bring wifi to RISC OS almost certainly paves the way for Bluetooth as well because the wifi part of the technology package is also on that same SDIO bus.

So when is the public beta released?

If you have to contact somebody to gain access to it it’s a private beta.

I gave this a test today and noticed it crashes the system if ADFFS is run as a Configure/Boot/Run task. The trigger appears to be when ADFFS performs OS_Module,3,“ADFS” so it can capture the ADFS DiscOp/MiscOp entries when ADFS starts up.

Oddly, if you either load !ADFFS manually after boot, or move !!Ip6Net from PreDesk to Tasks there’s no crash. The crash is so bad, debugger can’t even generate a crash log so I can’t provide any debug info to help here.

The second issue I’m seeing is NetManager triggers several ZeroPain errors whilst loading. I’ve yet to see if that’s related to anything else I have loaded, or the fact I’m using the today’s nightly ROM – if not it should be reproducable with ZeroPain loaded prior to launching NetManager.

Apart from those minor issues, it works really well…I’m impressed.

EDIT: I forgot to mention that if I use ifconfig wb0 via script too soon after loading NetworkManager, it says its connecting but doesn’t actually do it. I have to wait a while and then manually run the script to connect to the WiFi, so I can’t script it to auto-connect during boot

so I can’t script it to auto-connect during boot

I took an alternative approach (since I only have the one AP) and baked in something using the test script as a guide.

https://heyrick.eu/blog/index.php?diary=20240331

At the moment it does blind waiting between each stage. When the sources to either NetManager or the WiFi driver are available, I can look to see what it is actually doing to make things a little bit smarter.

I have to wait a while and then manually run the script to connect to the WiFi, so I can’t script it to auto-connect during boot

There are a couple of wait commands kicking around that might help if you run the task in the final bit of boot and wait. IIRC one such is on the pages of Vince Hudd.
I’m sure someone will pop up with a list of alternates

As the last two RISC OS Shows seem to suggest, I’d be tempted to ‘wait’ a few more days and potentially save all the effort.

Firstly, I think the next build to go out should resolve the need to wait for things too much – I need to test it here first, but the zips are waiting for me. Supposedly much faster/cleaner startup of both module and netmanager.

Secondly, if scripting, I’d probably look at creating a suitable profile for netmanager with the info in. NetManager will then auto login to the wifi network specified in the profile. You could also add any other settings you wanted at the same time.

For now, the profile info is in !Boot.Choices.Configdb but that may change (sorry – will try to keep you notified if you go that route).

Thanks Andrew, yesterdays build fixed the aborts I was seeing with ADFFS and creating a profile does cover the auto-connect at boot.

I am still seeing the zero page access with Network Manager though.

Do you plan to unify NetworkManager and the WiFi app into one app?

If you could email us zero pain logs for NetManager and/or how to reproduce, I’ll forward them on to the programmers to get sorted. That’s exactly the sort of feedback that will be very helpful to produce improved versions.

Very glad ADFFS issues are solved – perhaps just a bit of good luck there, but we’ve been tidying things up a lot as we go, and trying to smooth the edges.

Network Manager and Wifi into one app. Well, the thing there is that (by design) they aren’t exactly apps. (gasp). Instead they’re module tasks designed to function as modules both outside the desktop and inside. Essentially the logic is that you shouldn’t need to be in the desktop for important stuff like detecting network connections and switching wifi profiles to happen seemlessly.

So, they will likely remain separate modules. However, there has been quite a bit of discussion about perhaps unifying the UI so that there only needs to be one icon on the iconbar. Internally there’s a fair bit of debate on this – some people like being able to see both the Profile and the Wifi network at a glance, and regard this as better than other OSs. Indeed, if you have a lot of networks and several profiles, I can imagine it being useful. By contrast, other folks only use a single wifi network and really don’t care about profiles at all. Also, it kind of goes without saying, but a machine without wifi doesn’t need a wifi icon.

So, yes, we have plans to make both camps happy, although probably not in the next two days :)

Incidentally, it is worth saying that whilst the current version of NetManager probably seems quite tied in with Wifi, the intent is for it to manage both wired and wireless connections. It already allows for pretty much plug’n’play handling of interfaces – open the profile window, plug in a USB network adapter, watch it pop into existance in the interfaces list. (Guess what I’ve been doing this afternoon) :)

Andrew, I sent you some ZP logs on 27th March – they are still happening, usually in batches of 61 at a time, I have not checked the latest version is exactly the same though – I will try tomorrow.

If you didn’t want to commit to the beta programme but are wifi-curious, www.riscosdev.com (click “Projects”) now has the most recent stack and (beta) Network Manager for download. The latest stack includes the wifi driver, but the network manager still has a few rough edges which it why we’re still classing that as beta. It has, however, come on leaps and bounds in the last few weeks thanks to user feedback, but there’s still a little further to go. Have fun!

I suspect the ZP logs Martin sent cover what I’m seeing. It’s simple to repro, simply load NetworkManager and around 800KB of ZeroPain logs are produced either with or without any configuration done in the app.

Its probably worth asking your developer(s) and core testers to run ZeroPain by default to capture Null Dereference bugs early.

Regards the two apps, for wi-fI only NM isn’t really required. I initially commented it out and used ifconfig to connect the wi-fI which is why it wasn’t connecting without a wait. I can understand merging the apps would be a lot of work, so perhaps have the wifi app connect to the profile configured in NM, instead of having NM do it? Or do it similar to other OS, where the wifi app tracks the wifi profiles, although that’s probably a lot of work.

Having the app icons on the left feels a bit weird coming from Windows/Linux, although I appreciate that’s probably due to some arcane style guide requirement that’s out of step with the way we’ve come to expect things these days. I’m just so used to personal apps left / system-wide stuff on the right.

to run ZeroPain by default to capture Null Dereference bugs early.

Might I also suggest trying http://www.riscos.info/packages/DevelopmentDetails.html#Cppcheckarm to catch all manner of little whoopsies.

so perhaps have the wifi app connect to the profile configured in NM, instead of having NM do it

Yup. I didn’t want to clutter the iconbar (with only the one AP, it’s a bit over-complicated), so I simply threw together an Obey to do what needs done. It’s a bit blind-idiot right now (it just delays a while in between each step) as I’m not sure what the manager is actually looking for to automate it…but it works fine. I think I last rebooted on Saturday afternoon, it is still connected and working, no probs.

I’m just so used to personal apps left / system-wide stuff on the right.

Which is completely the inverse of the way RISC OS has always been (devices on the left, apps on the right).

Sounds like there needs to be some UI options somewhere, to please everyone. One icon, two icons, left or right… :)

Regarding developers and ZPP – they do, in fact, run ZPP all the time (the ROMs we develop on include ZeroPain baked in for just that reason).

Having had a chat with one of the programmers yesterday, focus has been on delivering NetManager functionality, and most of the ZPPs are related to the resolver module when interrogated in an uninitialised state – hence why they stop when you’re connected. This is a separate piece of work that we decided was best done after the show, so priority was on delivering the best possible Network Manager for Wakefield. I appreciate that an “Everything, everywhere, all at once” would be nice, but it was decided that non-fatal zeropains were less important than delivering smoother network management. I’m not saying it is the best call or not, just the one we made.

It is important to remember that the vast majority of users will not see those zeropains – only developers running the ZeroPain module.

Either way, I do personally thank you guys for raising this, as this kind of feedback is essential when I’m doing the “project management” part of my job.