Wi-Fi in 5.30

turn off all security on the router.

Can you please be more specific…
Are you talking about the encryption settings? (eg WEP, WPA, WPA2, WPA3 etc) Giving the working/non-working setting may help.
Or restricting the MAC addresses allowed to connect?
Or something else?

Can you please be more specific…

https://www.riscosopen.org/tracker/tickets/638

Can you please be more specific…

Gladly. My router has 4 encryption settings.

WPA+WPA2: doesn’t work
WPA2: doesn’t work
WPA2+WPA3: doesn’t work
open WLAN, no encryption whatsoever: works

Time for a new router, using anything less than WPA2 is highly inadvisable.

Well the “WPA2+WPA3” option should suffice then, shouldn’t it? It’s what is selected by default, and I only disabled encryption to get one file transferred to the Pi running RISC OS.
So I really can’t see the point in telling me to get a new router. But if there’s anything I can contribute to make a fixed version of the WiFi driver possible, I’ll gladly do it. Just trying to be helpful here.

(edit: I just realised, maybe I didn’t make it clear enough: “works” in this context of course means: “works with RISC OS 5.30”, and “doesn’t work” means “doesn’t work with RISC OS 5.30”)

For folks with Pi 400 who haven’t followed the bug tracker that Chris linked above, it would seem unlikely to work with WPA2 until there’s a fix from Broadcom:

“This looks like a problem with the Broadcom firmware blob, the Pi 400 is unique in which one it uses, and the one in the disc image appears to only complete the handshake for Open and WEP connections, timing out with WPA and WPA2.”

“Can you please be more specific…
Are you talking about the encryption settings? (eg WEP, WPA, WPA2, WPA3 etc) Giving the working/non-working”

=> Encryption settings that is word I was looking for ;-). Encryption setting : Open WLAN no encryption whatsoever that is the only setting which works for the Pi400 with RO 5.30

As stated by other it seems to be indeed an Pi400 issue only the other Pi’s I have seem to be working without issues.

As a new user to RISC OS, I found that on a small sampling of Raspberry Pi models (Zero W, 3A+, 3B+, 4B) I could only maintain a connection if wireless security was set to “*WPA2*” or “*None*” at the router. Any other setting would result in a network timeout or a RISC OS system lock-up.

Congrats to the RISC OS team for rolling out this critical feature. It was worth the wait.

Welcome to the forums!

Hi there,

I’ve been trying the WiFi support on the Pi4b using Risc OS 5.30, and albeit it “works”, connection tends to be very slow and unreliable (I’m using WPA-personal on my cellphone acting as a router).

For example, I can’t download files reliably via NetSurf because connection gets lost while downloading, and download speed is ~100KB/S (where the same file downloaded from a GNU/Linux machine using exactly the same connection method comes at ~5MB/s).

Is there anything to do to improve this? WiFi is very nice, but well…

WiFi is very nice, but well…

Same experience here, although I didn’t even take the time to test the reliability – the Ethernet cable was reconnected in within seconds!

RISC OS networking doesn’t like high latency networks.

See https://www.riscosopen.org/forum/forums/11/topics/13506#posts-87935.

A workaround is to use a local proxy that’s running on another OS.

e.g. pi-hole running on Raspberry Pi OS.

I updated to OnBoard WiFi Drivers V2 from here: https://www.riscosopen.org/content/downloads/raspberry-pi

…and now it’s even worse, it won’t even let me search in Google.
Fantastic. Really, I see this feature was expected and all, but has someone ever tested this?

As a test I plugged my phone into my router and failed over to it. Connection was two bars using 4G+.

Using curl downloading a file from riscosports.co.uk

Wired without proxy 150KB/s
Wired with proxy 5.5MB/s

Using latest WIFI modules.

Wifi without proxy 100KB/s
Wifi with proxy 1.5MB/s

Whilst I cannot speak directly for the ROOL wifi (I use the ROD wifi because it also works on my Pinebook Pro and iMX6), I have noticed that the portable module can have an effect on download speed via wifi. When the machine idles during download (ie. no other desktop activity other than downloading) it can slow the CPU, and with it the download performance.

For example, I typically see circa 1.5 MB/s transfers but these can drop if RISC OS decides to drop the CPU speed. Watching it rise again by swirling a window around the screen is rather daft. Something for us to investigate further, I think – a tricky one when combining it with wanting to preserve battery.

My gut says that there is more work to be done on the RISC OS SDIO support (which both wifi implementations make use of) as I think it is currently limiting performance compared to other OSs. To be fair, it was created “blind” without any drivers to connect to it, so it is only now that it is being exercised that we begin to see what might need further work.

I would encourage those having problems to try both ROOL and ROD wifi, and feed back findings (eg. via email) to the respective parties so that things can be enhanced in future releases.

Was the 16th May release a national secret? If it weren’t for this thread…

Might be very slow but fixes the connection issues I had, without having to change my router’s security settings.

The same tests using my broadband connection. This maxes out at about 3MB/s. Didn’t seem to make much difference running the CPU @2.4GHz or 600Mhz,

Wired without proxy 200KB/s
Wired with proxy 3MB/s

Wifi without proxy 130KB/s
Wifi with proxy varied between 1.5MB/s and 3MB/s

Transferring a file from a local web server.

Wired 80MB/s.

Wifi varied between 2MB/s and 3MB/s. The signal strength was 89% (very good).

Can I guess that the proxy server is on a wired connection?
and second guess is that the path from disk of web server to wired client is 1000Mb/s all the way? (80MB/s being 800Mb/s approx)

NB. Wi-Fi is a contended network and therefore bound to be slower.
The degree of slower will depend on the amount of non-unicast traffic in the network segment from other devices than your source and destination.

RISC OS networking doesn’t like high latency networks.

We can even say RISC OS does not like networks :)

New TCP/IP stacks touch the limit of what RISC OS can do. For example, it’s not recommanded to use the ROD stack on overclocked Pi. On my FAST, where all the interrupts are eaten by the driver of the very fast SATA interface, it almost doesn’t work at all (very slow transfer rate, and frequent time out, even with simple tasks as a web search).

Under NetSurf, it will be very difficult to get more than 2 MB/s, even with a multi gigabit/s FTTH connexion. It’s a bit better under FTPc, but when sending a mail to a secured SMTP server, it’s slow as hell, and my computer can’t be used while the transfer is not finished. I’m not suprised Wifi connections are slower, since the CPU has much more work to do to support them.

Communication with a local SMB server is much better.
That’s networking under RISC OS.

A similar test downloading from a local web server but using Raspberry Pi OS as the client.

Wifi using curl to download gets 12MB/s. It can vary slightly but the download speed is much higher than RISC OS and more consistent (Maximum on RISC OS seems to be about 3MB/s, can drop to 1.5MB/s).

Looks like there’s a bandwidth issue as well as latency using RISC OS.

Under NetSurf, it will be very difficult to get more than 2 MB/s, even with a multi gigabit/s FTTH connexion.

NetSurf tops out at about 19MB/s downloading from a local web server here. So if you’ve got a fast connection using a local proxy is the way to go.

I’m not suprised Wifi connections are slower, since the CPU has much more work to do to support them.

I’m not seeing Wifi being affected by CPU here. It’s slow because of network latency and RISC OS not being able to use all the bandwidth available. The exact same hardware using Raspberry Pi OS is fine.

Of course, but Raspberry Pi OS is a completely different offer. On the Pi4 the bandwith shared between the SD Card and the Wifi chip is 200 Mb/s. So 12 MB/s (AKA more than 96 Mb/s) is very good. On Ethernet, we are more close to the Pi limit (I believe it’s around around 433 Mb/s).

Bandwith is a problem under RISC OS. And you’re right to say latency is too. The effect is more visible on systems that are under heavy pressure from interrupts, as the FAST (or even overclocked Pi). But I suspect some fine tuning of timings could help.

On Ethernet, we are more close to the Pi limit (I believe it’s around around 433 Mb/s).

There’s no limit to wired network speed on the Pi 4. Raspbery OS gets 104MB/s download speed and on RISC OS to a ram disk 80MB/s. To a SATA drive on RISC OS it’s about 40MB/s.

New TCP/IP stacks touch the limit of what RISC OS can do.

I wonder how much of this is the underlying architecture? When I was playing with making a little MP3 player with OLED out of a Pi0 (trading the code on a regular Pi), I gave up as writing to the OLED took longer than the low level audio buffer so the music kept breaking up. It seems the OS has something of a habit of banging off interrupts when it needs to “do stuff”.

Under NetSurf, it will be very difficult to get more than 2 MB/s, even with a multi gigabit/s FTTH connexion.

I’ll let you know when I get fibre. Right now, my connection maxes out at around 240KiB/sec.

By the way, your MB/s. Is that Megabit or Megabyte?

Looks like there’s a bandwidth issue as well as latency using RISC OS.

Hasn’t that always been the way? Unpacking a big zip file using SparkFS can take minutes under RISC OS (tested back in the days of the Pi1). Windows running 7zip on a slower processor (466MHz Celeron, if I recall) did it in about twelve seconds. It has always seemed to me that FileCore is a tad slow.

Have you tried downloading to a Fat32FS drive, or to RAMdisc?