Running a file server on RISC OS

Ok so this works now!

awServer running on one Pi turns up when you do “Net > FS list” on the other.
My Notify program that I wrote many years ago works fine between the two Pis (again uses Econet SWIs): https://github.com/davegardnerisme/riscos/tree/master/notify

The fix – which is sort of obvious in hindsight – was that I had edited a saved copy of the AUNMap file, but not the actual one used to configure it. Once I did this, it worked fine using my existing LAN setup (192.168.0.0/24). The machines can see each other now via Econet, and access the Internet which is nice.

In related news I stumbled upon this:

http://mdfs.net/Apps/Networking/FServers/

Thanks for all the help everyone!

So you’ve set it up to use a 192.168.×.x address (I trust the station number is the last digit, as the Orange Livebox uses 192.168.1.x) and it happily coexists with TCP/IP? And ShareFS as well?

If so, I’ll have to fiddle around with AUN to have a go at getting that working. I wonder… is the underlying AUN protocol documented? Might be fun to fire up my ancient VisualBasic to see about accessing the file server’s stuff from within Windows ¹.

¹ Don’t get your hopes up, I use XP…

> So you’ve set it up to use a 192.168.×.x address (I trust the station number is the last digit, as the Orange Livebox uses 192.168.1.x) and it happily coexists with TCP/IP? And ShareFS as well?

Yes!

> I wonder… is the underlying AUN protocol documented? Might be fun to fire up my ancient VisualBasic to see about accessing the file server’s stuff from within Windows.

Yes! That sounds amazing. I’m happy to dig into that a bit as well. Keep me posted if you find anything. I’m currently trawling through the awServer source because there was an app I perpetually rewrote back in the 90s, without actually ever finishing it, and I have some strange desire now to actually finish it. That’s the “MailServe” app (which was supposed to be something a bit like Mailer!) https://github.com/davegardnerisme/riscos

Yes!

Hmm… NetI fails with File ‘Resources:$.Resources.Econet.Messages’ not found.

I’ve hacked the NetI module to not only branch to the alternative (Resources.Net.Messages) but to also put a dummy message in place of the above, in case there’s somewhere else in the module that calls it (though I didn’t find anything)…

…and the NetI initialise still fails with File ‘Resources:$.Resources.Econet.Messages’ not found.

I give up. That string is not present in the module, and I don’t feel like taking the source apart to try to figure out what’s going on.

I’ve commented out the Econet stuff. Just ShareFS and TCP/IP again. Maybe some other day.

Argh that is unfortunate. My knowledge (lack of) will definitely not help you out here.

If I make any progress on the protocol, I’ll make a thread or something. So far I’ve learned that it’s mostly UDP for transport: http://www.riscos.com/support/developers/prm/aun.html

And maybe the source code is somewhere in here: https://gitlab.riscosopen.org/RiscOS/Sources/Networking/AUN/Net/-/blob/master/c/swis#L21

So you’ve set it up to use a 192.168.×.x address (I trust the station number is the last digit,

192.168.net.station probably sums it up.

as the Orange Livebox uses 192.168.1.x

That one of those horrible beasts that use x=253 or 254?

That one of those horrible beasts that use x=253 or 254?

.254? No, that’s the Econet file server. :-)

The Livebox is, thankfully, 192.168.1.1, a sensible number. Though it is hardwired. My intranet (pre-Livebox) was 192.168.0.×. Oh well, I only needed to reconfigure everything once.

You can even reserve specific IP addresses for certain MAC addresses, so the same device will be DHCP allocated the same IP. Like the inkjet is 192.168.1.14 and the laser is 192.168.1.17 and…
It’s actually surprisingly useful for an ISP-supplied box.

While I’m supposed to be using a Livebox 2, John (thanks John!) gave me his old Livebox Play (or Livebox 3) which supports 5GHz WiFi and IPv6. Thankfully even though the inkjet uses IPv6, I can talk to it via IPv4 because I can remember 192.168.1.14 a heck of a lot better than I can remember all those numbers that make up an IPv6 address!

.254? No, that’s the Econet file server. :-)
.254 is the printer, in the wife’s office. Mind you printing at home is not something she’s done for a few years, so it probably doesn’t work.
Hmm, mr. ping say no. Probably been turned off.

I can talk to it via IPv4 because I can remember 192.168.1.14 a heck of a lot better than I can remember all those numbers that make up an IPv6 address!

I don’t have to deal with IPv6 at present:

1. At work someone ensured nothing was forwarding IPv6 traffic, most of the kit doesn’t do IPv6 and nobody with a brain runs a dual stack.¹
2. I may bother learning the quirks, then again I may retire, but I do know that the systems at work see my incoming connection from home as an IPv6 address.
3. I have a mental list of Domain controllers, DHCP servers, NTP servers, my virtual PC and various other critical kit – in IPv4 of course.

¹ Folks, if you have a default Win10 install, look up the details of shutting down the IPv6 support. It will speed things up. If you live long enough to have no choice then IPv4 is probably defunct and that’s the bit you kill off.

it will speed things up.

That’s generally brokenness elsewhere. Like if you are running IPv6 and connect to a domain that is only IPv4, your software is first going to ask for a DNS lookup for an IPv6 record (AAAA). At which point it may receive no reply whatsoever, and have to wait for a timeout before retrying with an IPv4 request (A).

It’s not IPv6 that’s broken, it’s the DNS server.

At which point it may receive no reply whatsoever, and have to wait for a timeout before retrying with an IPv4 request (A)

Actually, f you check such things, what you get these days is both IPv4 and IPv6 information.

The issue with slowness is running the dual stack.
It’s slow for two reasons:

1. It’s more work running both
2. The proponents of IPv6 have made sure your system running dual stack tries to do things IPv6 first and then retries with IPv4. They argue IPv6 is faster and “prove” it by letting you try a dual stack and then a single IPv6, misleadingly not allowing the IPv4 only.

IPv6 isn’t broken, nor is IPv4 inherently slow. IPv4 has limitations in the case of address space¹ IPv6 can deal with more.

¹ Which wouldn’t be a problem if a certain country hadn’t grabbed stupid large portions of the range. Why do Apple have the whole 17.0.0.0/8, and then start using every damned address range except 17.0.0.0/8 for their support servers?

Hmm… NetI fails with File ‘Resources:$.Resources.Econet.Messages’ not found.
I’ve hacked the NetI module to not only branch to the alternative (Resources.Net.Messages) but to also put a dummy message in place of the above, in case there’s somewhere else in the module that calls it (though I didn’t find anything)…

You don’t seem to mention which version of NetI this is. NetI 6.26 and later should carry its own messages and no longer rummage round in Econet’s underwear drawer; it certainly loads OK on my Titanium and there’s no sign of an Econet directory in ResourceFS.

NetI 6.26 and later should carry its own messages

Great, I’ll grab the harddisc4 archive and pluck out the latest. That ought to sort this, then.

Dave,
I am very pleased

> Ok so this works now!
> awServer running on one Pi turns up when you do “Net > FS list” on the other.

AUN is not !awServers original use case and there may be cases where it uses Econet specific calls.

Do you have the fully commented source or the striped version. The fully commented version is very much more useful as a reference to the protocol. It was also a bit of diary, and a monument to my level of literacy, but luckily its all to long ago to be too embarrassing to admit to.

I have recently been trying to get the AUN layer up between a PI and a RPC (4.39, with both both AUN and native Econet) but I have not been successful with that. I have been meaning to try two pies and I am pleased that you have proven that to work.

I am not sure I can fix !awServer any more I embarked on a host of UI extensions and never got it finished because I realized my folly of not writing it in ‘C’ in the first place. So I also have a half finished attempt at a portable ‘C’ version which, after 20 years, I spent an hour on the other day. My original idea of portability was to have a RISC OS version and a Netware version, now I suspect Linux instead.

I would quite like my NAS to speak NetFS/AUN but the code to support AUN sockets has gone from the Linux kernel so each app would have to roll its own now.

I have been wondering about Level4 on a pi, I have not tried this yet but I think getting the new ABClib for the pi might help it run. (Its design use case is AUN rather than Econet)

For AUN another server that might be worth looking at is ‘aund’, this is a linux app that implements only the subset of the NetFS protocol used by RISC OS clients. It may need a very old linux kernel to run on. I think the reasoning is that linux doesn’t have native Econet so no such clients could ever connect.

Its also been occurring to me lately that we may have to do some updates on the client and server sides to support modern file sizes and start to spec out what the 64 or 128bit extensions to NetFS might look like.

Alan.

Alan,

Thank you very much for writing this!

I think I only have the stripped source; it’s not fully “minified”, but lacks any comments. If you could point me at the full source that would be great.

My journey back to RISC OS is definitely starting with nostalgia. I have a programme I kept re-writing in the mid 90s; something akin to Mailman. I was fascinated by the idea of network apps. My problem back then was that whenever I got to the point where it was close to being finished, I’d start again because I’d decided it needed to work differently. This was all in BASIC.

I’ve found that old habits die hard and I’ve now started rewriting again in C this time, having read Steve Fryatt’s excellent series on programming in C. https://www.stevefryatt.org.uk/risc-os/wimp-prog

I do like the idea of trying to document the Econet-over-IP protocol so I could build something that runs on my Mac for example. I think I will try to finish my toy mail programme first though!

Do you have the fully commented source or the striped version.

Stripped, I think that’s the available one…

The fully commented version is very much more useful as a reference to the protocol.

Please tell me you have uploaded a copy somewhere.

The last time I read through awServer (yikes, like a quarter century ago!), it was in tandem with numerous bits of documentation. That dinky little spiral bound (ish) manager’s guide. The PRM, and….

BTW, are you aware that JGH took awServer, made it an MDFS, fixed some bugs, and added ATOM support? http://mdfs.net/Apps/Networking/FServers/SoftMDFS.zip

LOL no I had no idea but incredibly I stumbled over that very fact today over here: https://stardot.org.uk/forums/viewtopic.php?t=9407 having read about it in this thread.

By the looks of it JGH’s download would be a more useful thing to point people to these days than mine given the improvements he has made to it.

I have just uploaded a zip of a folder of Econet stuff from my RISC PC which includes the awServer source with comments along with a bunch of other things some mine some not.

https://peppertreeit.com.au/acorn/

Alan

https://stardot.org.uk/forums/viewtopic.php?t=9407

Holy Hell, somebody reverse engineered the MDFS and then built their own?

< mind blown emoji >

I think an easier way might be to run SoftMDFS and then see about getting an Econet card talking to a Pi… No idea how though. And I think it might need a lot of GPIO.

Yep I was pretty impressed with that too. Interestingly he was stumped by the contents of the PAL chip.

This is always the challenge trying to do Econet not using a 68B54 which has the zero insertion and deletion and flag generation and detection done in silicon.

Its very likely the PAL does at least some of those things and then hands the bit stream & clock on to the Z80 SIO chip.

A Econet Hat would very probably be done with a CPLD or FPGA that could convert Econet bit steam to SPI and back.

At the moment I am working towards, in as much as its built on on a breadboard, seeing if zero insertion and deletion and flag detection can be done on the RPI PICO PIO state machines. (this could take me any length of time)

Add an SD Card and you can see where I am going. There is an Arduino Filestore but I think PICO one would give a lot more space, and be a tidier build.

I think it would be interesting to build the BRANDY basic interpreter for the PICO (+vga display, PS2 kbd etc) and I was thinking awServer on that but I would rather work on my C version (NetFSFS) as this would also better suite a PI with a Econet Hat, linux with USB Econet if/when etc.