Is remote booting still possible?

While reviewing the User Guide I found the section “Remote booting with Access” on page 163. It discusses connecting to a shared disc containing !ShareBoot and using that as the configured boot device.

Out of curiosity I decided to give this a go and see whether it works. I created a shared disc on my Pi 3 named NetBoot and put a !ShareBoot onto it as instructed. I confirmed that it was visible from my Pi 1, went to “Save choices”, then did “Configure ShareBoot NetBoot”¹ and “Configure FileSystem Share”.

Rebooting the Pi 1 gave me “Shared disc ‘NetBoot’ not yet seen” and after a 45-second timeout it gave up.

Is this supposed to still work under the current OS? If so, what am I doing wrong? I should note that I do not get the usual messages about DHCP; are things loading in the wrong order? Does it require static IPs? Or, for that matter, are the necessary dependencies actually in ROM?

Edit: Changing to static IPs didn’t help.

¹ The User Guide doesn’t say to do this, but I saw it listed elsewhere when I was doing some research.

Solution
Since the thread got a bit long and sidetracked, here are the important bits.

• On the server, create a shared disc containing everything from HardDisc4. Rename !Boot to !ShareBoot (and update the sprites accordingly if you wish), and create the !ShareBoot.MchConfig and !ShareBoot.Resources.!Scrap.ScrapDirs directories (the latter already exists in 5.22 but not in the current nightly).

• Share the disc without “-protected” as we haven’t yet figured out the right permissions to get everything working.

• On the client, do this:

Configure FileSystem Share
Configure BootNet Off
Configure FreewayAutoAddress On
Configure ShareBoot DiscName

That should be enough to get everything working (on a network that uses 10.×.×.x addressing).

I can’t get it to work either. I have half a suspicion that the 45s timeout is not sufficient. With the configured filesystem as ADFS, a normal !Boot start up, the nominated remote Share is slow to mount. This is attempting to get the Titanium to boot from a Share on the (slow?) RPi3, perhaps it is worth trying it the other way around.

P.S. That didn’t work either.

That’s an interesting suspicion but I’m not sure whether that’s actually the case (on my network, at least); if I boot from SDFS then the shared disc becomes available within 10 seconds.

https://www.riscosopen.org/forum/forums/11/topics/3993 Hmm!!

On your Pi which is failing to boot via ShareFS/Access, do you know the network configuration at the time it is trying to boot?

Typically, the Boot structure (on your SD card) will eventually configure the network, probably via DHCP. But if you configure booting over ShareFS then this will not have happened.

Try changing the boot option to NoBoot and letting the system start without running any boot structure. Can you determine the IP address and netmask? Careful use of *ifconfig may help.

Thanks for the link, and the ifconfig suggestion.

I needed to *Configure BootNet On to make the network functional without having seen !Boot first. However, it’s using the IP address 1.0.128.255 and I can’t figure out how to change it. Can anyone advise what to do here?

I’ve clearly been spoiled by the GUI :)

Edit: This page on ROL’s site says that “SetStation sets the full four byte IP address in CMOS RAM” but the copy of SetStation in ROOL’s CVS says that “it pokes IOC and has various other 26 bit delights in it” so I’m not sure whether it’s even worth trying!

I’d imagine that it could be useful if the “full” configuration system in !Boot could do the same job as SetStation and save the IP address into CMOS rather than only saving it back into !Boot, but I digress…

Edit 2: After a bit more digging, I found this which mentions that “ReadCMOSIP” will grab the configured CMOS IP address and drop it into Inet$CMOSIPAddr. After grabbing the source from CVS I found that the IP address is stored in bytes 108, 109, 110 and 0. I did this in BASIC:

SYS “OS_Byte”, 162, 108, 10
SYS “OS_Byte”, 162, 109, 0
SYS “OS_Byte”, 162, 110, 1
SYS “OS_Byte”, 162, 0, 205

Then I ran ReadCMOSIP… and it returned 10.0.1.255 (not 205)! Where is this 255 coming from?

Note that I also tried putting 205 into byte 111 (it’s only logical) but that didn’t help either.

PS. If 108-110 are the correct places for the first three bytes then OS_Byte CMOS Settings probably shouldn’t say that they’re reserved for RISC iX :)

Edit 3, because this post wasn’t enough of a novel already: PRM 1-373 states that OS_Byte 162 allows you to write to CMOS bytes, “with the exception of location zero, which is protected”. Wonderful. So how do you set it? I tried to do a SaveCMOS, hex edit, and then LoadCMOS but that failed due to the checksum (which I’d forgotten about). The PRM doesn’t seem to say how the checksum is calculated.

Then I ran ReadCMOSIP… and it returned 10.0.1.255 (not 205)! Where is this 255 coming from?

I normally associate .255 with broadcast addresses, so perhaps the system is broadcasting a request in the network defined by the first three values. (Assuming originally net 1.0.128.0/24 and now 10.0.1.0/24)

Have you tried running wireshark on a PeeCee and watching what gets sent? You might have to connect both devices into a mini-hub to ensure ALL traffic, including unicast, gets to the PeeCee.

I found out that 255 is the default value in CMOS location 0 (confirmed with both OS_Byte 161 and by attaching a hex editor to the CMOS file). The current question is how to change it.

I found out that 255 is the default value in CMOS location 0 (confirmed with both OS_Byte 161 and by attaching a hex editor to the CMOS file). The current question is how to change it.

Perhaps you’re not meant to change that and it’s actually intended to produce a setup that broadcasts requests on that 10.0.1.255 (with a mask of 255.255.255.0) thus ensuring everything in the 10.1.1.0/24 network will see the requests and broadcast back the required response¹ and then the boot sequence sets a possibly different IP.

Bear in mind that the remote boot stuff may well be using BOOTP rather than DHCP (similar but not the same). A typical BOOTP or DHCP client gets its network setup assigned from the remote end.

If you’ve got a PeeCee I really do recommend running wireshark to capture the network “conversation” to help figure out where the sequence is failing.

¹ That’s the exact behaviour of DHCP DORA sequence hence the requirement for DHCP relay (IP helper in Cisco speak) when the traffic has to pass through a router to a different network segement.

Bit of a stab in the dark, since I have not used any of this stuff for a LONG time! Does the ‘CMOS IP’ stuff that you have discovered perhaps only set the first three values, and leave the final one for the old SetStation utility? (which may store in a different part of CMOS)

I am not convinced that you need BootNet on, as that is mainly for the Level4 file server sort of stuff. It might be handy for getting a fixed IP though.

I vaguely recall that you can have Access without Net, but it may adopt a different IP scheme.

I’ve done some more research and I think I understand what’s going on now.

CMOS bytes 108-110 contain the first three values, and byte 0 contains the final value, reusing the old Econet station ID CMOS location. This location is protected so that clearing CMOS doesn’t wipe the station number (and therefore potentially create an addressing conflict).

In the old days, SetStation let the network administrator configure the station number. This doesn’t use OS_Byte 162 but rather updates the value some other way. The CVS logs on SetStation imply – but don’t explicitly state – that it won’t run on a 32-bit machine.

The default value is 255 and it appears that this is not related to broadcasts but rather that Acorn chose to put an invalid number in as default (again, probably to avoid potential conflicts). With that said, I haven’t tried Wireshark on a “PeeCee” (after some confused Googling I’ve concluded that this is Steve’s name for a Windows PC, rather than some oddly-named network sniffing device; bear in mind that there’s a similar device called a Pineapple, although I don’t have one of those either).

Does all of that sound correct so far?

With BootNet off and Configure NoBoot, I do not get the Access icon on the icon bar. With BootNet on, I do. I therefore suspect that I do need it on, but I’m happy to test both options once I have the IP address configured.

I still need to try SetStation; as stated above I got the impression that it won’t work but I haven’t actually tried it.

… I’m no longer convinced that I’m on the right track. After looking at the code and having a play with *IFConfig, it seems that ReadCMOSIP is the only thing in the entire OS that actually reads those CMOS bytes… and it doesn’t seem to actually be called unless you specifically run it. So now I’m back to square one!

With that said, I haven’t tried Wireshark on a “PeeCee” (after some confused Googling I’ve concluded that this is Steve’s name for a Windows PC

1. Sorry for the confusion but Wireshark runs on Windows, Linux and a limited port even exists for RISC OS so a loose generic label for a box that can run Windows or Linux seems appropriate.
2. Since PC appears in the name of the elderly StrongARM beast sitting upstairs that version is right
3. PeeCee isn’t something I personally came up with

So back to the bit about capturing the network traffic to see what you have happening or not…

I had a quick go with SetStation (as in Sources.Networking.Econet.utils). After changing the obvious PSR → pc manipulations to be 32-bit, the initial validations on station now seem to work. However, when I gave it a valid station it Data Aborted because in subroutine5 there are LDRB and STRB at R0,[R2,#Legacy_IOCControlSoftCopy]. I have no idea what that is, but it seems r2=0 and Legacy_IOCControlSoftCopy=262 so the LDRB ‘works’ but the STR aborts.

SetStation contains its own copy of the IOC/IOMD IIC driver so that it can bypass the protection checks in the OS.

Under RISC OS 5, there’s actually an (undocumented on the wiki) OS_NVMemory 7 call which can be used for setting the station ID. However it looks like current kernels are built with ProtectStationID set to true, so you might have to crack the CRC-based password check first!

Actually, it looks like Sprow is responsible for adding that reason code in 2014, so if you ask nicely he might be able to supply the password (or a suitable RISC OS 5 SetStation implementation).

Please let it not be “password”! :-)

Why are we still protecting the Econet station ID in 20xx?

For desktop RISC OS 5, I suspect the protection is mainly there to stop the value accidentally being clobbered by *LoadCMOS, or dodgy software which accidentally writes to CMOS (or the wrong CMOS location).

I’m not sure of the worth of using a CRC though.

The references to IOC are because the Econet station ID was protected to the extent that the SetStation utility had to bit-bash IIC directly to the CMOS RAM. It has no relevance today (except maybe the RiscPC).

There was the mentality that the station ID was “special” and should not be touched, perhaps this persists in the idea of using a CRC to protect the value?

…I’m no longer convinced that I’m on the right track. After looking at the code and having a play with *IFConfig, it seems that ReadCMOSIP is the only thing in the entire OS that actually reads those CMOS bytes… and it doesn’t seem to actually be called unless you specifically run it.

There’s some floundering going on here! ReadCMOSIP was an alternate method of setting the address which was added for Set Top Boxes (no harddisc), but it’s not desperately useful in a desktop world. It’s still there in InetSetup, as detailed in the Setting up networking chapter of the User Guide written by, ahem, Chris Mahoney.

Because we’re always trying to save precious CMOS bytes, the bottom byte of the IP address is overlaid with the Econet station id; that makes sense, because in AUN the bottom octet of an Econet-over-IP address is the Econet station anyway (see NetI and AUNMap). But, since the station id is protected most often it’ll be 0 or 255 if otherwise unset.

Under RISC OS 5, there’s actually an (undocumented on the wiki) OS_NVMemory 7 call

I’ve added the wiki page. One day we should finish the job and update SetStation to use it, at the moment the source is scraped off the bottom of a shoe. It poked IOC directly precisely because CMOS location 0 is protected – there was no (legal) API to write it without poking IOC, which I recognised as nonsense in a HAL system so added the OS_NVMemory subreason.

Anyhoo, flicking to the boot setup page of the Titanium Quick Start Guide, I see that to boot from a ShareFS server you need

*Configure FileSystem Share
*Configure BootNet Off
*Configure FreewayAutoAddress On
*Configure ShareBoot MainServer

Now, there’s a bear trap with FreewayAutoAddress which picks a 10.×.×.x’s based network address on RISC OS 5, but earlier versions used a 1.×.×.x’s based address, so you can’t mix and match, otherwise neither will see eachother. There’s also a bug that means some combinations in InetSetup are invalid (I don’t have my notes to hand, I think it’s when TCP/IP is turned off).

BootNet’s pretty much a dodo module. Several times I’ve figure out what its for, but as it’s still flapping its wings there must be something I concluded it did.

Now, there’s a bear trap with FreewayAutoAddress which picks a 10.×.×.x’s based network address on RISC OS 5, but earlier versions used a 1.×.×.x’s based address, so you can’t mix and match, otherwise neither will see eachother.

It is posible with a server with a i3 etherlan card. A i3 etherlan card, EtherH, you can give two network addresses, for example a 10.×.×.x’s based network address and a 1.×.×.x’s based address.

It’s still there in InetSetup, as detailed in the Setting up networking chapter of the User Guide written by, ahem, Chris Mahoney.

While I checked/updated the bulk of the chapter, it seems that ROOL did that particular bit; it’s changed since the 3.7 guide but isn’t one of the submissions I made. No blaming me! :)

However, it’s one of the things I caught while reviewing, hence this thread.

Now, there’s a bear trap with FreewayAutoAddress which picks a 10.×.×.x’s based network address on RISC OS 5

Hmm… I did try enabling FreewayAutoAddress and still ended up with a 1.0.128 address. It seems that I may be hitting line 1159 of castle.RiscOS.Sources.Networking.AUN.Net.c.mns:

/* else make Internet address from station specified into 1.0.128. */

… which was found by doing a quick search for “1.0.128”. It may also be stored in separate bytes somewhere though so who knows whether I’m actually hitting that particular line or not…

Anyway, I have to go to work now so don’t have time to read the rest of the file at the moment.

Please let it not be “password”! :-)

Of course it really should be Password123 because sticking in numbers and uppercase makes it more secure – that was obviously the reasoning behind the even more secure P@ssword123 for the admin on an internet based demo system a manufacturer provided a few weeks back. Yep, honest.

Now, there’s a bear trap with FreewayAutoAddress which picks a 10.×.×.x’s based network address on RISC OS 5, but earlier versions used a 1.×.×.x’s based address

10.×.×.x (private) vs. 1.×.×.x (misused real world address)
Yes, incompatibility issue but at least it corrected the “illegal” use case Acorn created

else make Internet address from station specified into 1.0.128.

Bug. 1.×.×.x is real world allocated (Asia-Pacific I think) hence the change to 10.×.×.x private addressing.

P@ssword123

Yeah, that reminds me of XXXXing ARM. I just wanna log in and download a datasheet. Why does ARM, for that, require the most stringent password of any of the services that I am a member of?
That’s not to say that a password shouldn’t attempt to have some measure of security, but – you know – something like correct horse battery staple is memorable, whatever the hell I used with ARM… not so much…

change to 10.×.×.x private addressing.

Shame they didn’t go with 192.168.×.x like just about every LAN I’ve ever seen¹ – there are enough numbers there to totally satisfy Econet’s bridge network requirements – 192.168.1.10 can map to station 1.10, 192.168.2.254 can be station 2.254…Etc…

¹ Admittedly, that’s home networks and small businesses. I can’t count my current place of work because they still use freakin’ WEP (!) so maybe it’s just a glorified home LAN?²

² Which reminds me, since I’m here – the server box and outgoing line are connected to the rest of the building by way of three 24 port Cisco switches. It’s a horrible mess of cabling. (I know this because the place this is located is… the adminstrative broom closet!) Anyway, when there is data being transferred lights blink. That’s normal. What strikes me as not normal is that all of the lights of each connected port blink. Together. Surely a switch should have taken a note of the MAC of each device connected so as not to choke the available bandwidth by spamming the same data packets to every machine? Sorry to ask, but it just bugs the hell out of me every time I go in there and see it behaving like cheap Christmas lights…

my current place of work

We use “10.building.storey.x” addressing so that we have a rough idea of where a given device is. Obviously this doesn’t hold up for Wi-Fi but that’s a minority of our devices.

I also use 10. addressing at home but that’s just because it was the default on my AirPort base and I’m too lazy to change everything :)