ShareFS DIscs

How does ShareFS recognise remote computers that have a shared disc so that it can add them to Resources:$.Discs? I have several computers on a network, including Iyonix and VRPC (both of which have a drive that is shared) but my Panda can only see one and my Pi can only see the other. If I swop over their network connections (Panda and Pi), they can still only see the share they saw before. There must be a simple solution!!

I think ShareFS advertises discs via broadcast. Transmission and reception of broadcast can commonly be affected by two things:

• a wrong netmask, which therefore uses the wrong broadcast address;

• a firewall that doesn’t let broadcast traffic in.

Many thanks. I can reject both of these as in each case the fact that a drive is shared is received, just not by both computers.

Actually, until you have checked both you can’t come to that conclusion particularly if you have a firewall rule that allows traffic from one address but not another.
Not that I have any work experience of networks and firewalls¹ you understand.
Always best to checkrather than assume.

¹ That may be a small porky

I don’t think that either Panda or Pi have a firewall.

If A can see B, and C can see D, is it possible that A&B have a different netmask to C&D? Would this give the observed symptoms? As they are all RISC OS machines surely none are running a firewall?

If A can see B, and C can see D, is it possible that A&B have a different netmask to C&D?

Yes. The symptoms are typical of that, however one would assume¹ that Chris had actually checked that aspect.

As they are all RISC OS machines surely none are running a firewall?

Wrong :)

One is VRPC and therefore on either MAC or Windows where firewalls come into play.

¹ This does of course break one of my rules: “Never assume”. This afternoon was an example of checking to make sure that a fully trained PET scanner engineer hadn’t configured a default gateway on more than one NIC and improving things no end by removing the erroneous entry.

Afraid I have nothing helpful to add. other than that I have an Iyonix, PandaRO, BB, each with two drives shared, and an RaPi sharing it’s single drive, and I have never had a problem with any of the machines not seeing any of the other shares.

Dave Symes has reported this week in the comp.sys.acorn.? newsgroup what seems to be exactly the same problem. Following many suggestions no solution has been found:-(

Have you tried setting sharefswindow 1 on the iyonix and vrpc I found I needed it on the other machines – ie not the one I thought I had a problem with.

The only “problem” I have, if I share a device “full” (r/w) nit all directorys are visible via ShareFS. It looks like (not sure) the access rights of the files inside are the reason. If any protected files inside, the Dir is not visible. I have unprotect the content of a unvisible folder complete and it was visible after refresh.

I have set ShareFSWindow 1 { > null: } on both VRPC and Iyonix [in Choices.Tasks]. My Iyonix has a static IP address and a netmask (192.168.1.12 and 255.255.255.0), all addresses are 192.168.1.x and the other machines (VRPC, Pi and Panda) have no netmask as they use DHCP. Hope this helps. A can see B and C can see D and this remains the same even if the network connections to A and C are swopped over. I have a switch not a hub so broadcast messages might get suppressed unless they are addressed to a specific machine?

Is there a way of telling Resources:Discs about a specific external machine other than receiving a broadcast message? There must be because you can ‘Save Choices’ and the disc icon will be there on start up before it receives a broadcast message and will get greyed out if it doesn’t respond when asked… I can’t find where these choices are stored.

I have set ShareFSWindow 1 { > null: } on both VRPC and Iyonix

I suppose you have tried having it set on all computers?

the other machines (VRPC, Pi and Panda) have no netmask as they use DHCP

Of course they have netmasks, but just not ones assigned by you, so they could well be wrong. I use a 10.×.×.x address range here, and my old router (before it overheated) didn’t have an option to set the netmask to 255.0.0.0 in the drop down menu, which led to mismatches where a machine set the netmask from the class type and others didn’t.

Use

ifconfig eb0

Armini can see VRPC share and Panda can see Iyonix share
DHCP addresses are in the range 192.168.1.1xx (but I have address
reservations in DHCP for printers below 100). Hence Armini (192.168.1.104 in this session). So the only machines on which I explicitly set the netmask is the Iyonix and Panda (both with static IP). The Armini gets it via DHCP and VRPC no doubt from Windows. Where I set the netmask explicitly, I set them to 255.255.255.0 because I know that only addresses in the range 192.168.1.xx are used on my network. Hope this helps. Output from ifconfig below.

So it looks like computers with static Ip can only see other computers with static IP and computers with DHCP can only see other computers with DHCP. Weird.

I have now set the netmask for Iyonix and Panda to 255.255.0.0 and (other than generating extra unwanted broadcast traffic) all is well. Many thanks.

----------
VRPC:
*ifconfig en0
en0:    flags=8043<UP,BROADCAST,RUNNING,MULTICAST>
        inet 192.168.1.73 netmask 0xffff0000 broadcast 192.168.255.255
IfConfig: kvm_nlist(): Unimplemented SWI
*
---------
Panda
*ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255
        ether 02:95:48:eb:a8:13 
*ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
*ifconfig ej0
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255
        ether 02:95:48:eb:a8:13 
*
----------
Iyonix
*ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
ek0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.12 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:09:95:00:14:96 
*ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
*ifconfig ek0
ek0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.12 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:09:95:00:14:96 
*
----------
Armini
*ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.104 netmask 0xffff0000 broadcast 192.168.255.255
        ether 02:59:f4:22:a7:96 
*ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
*ifconfig ej0
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.104 netmask 0xffff0000 broadcast 192.168.255.255
        ether 02:59:f4:22:a7:96 
*

I suppose you have tried having it set on all computers?

No.

Not weird, but as configured:
VRPC: netmask 0xffff0000 broadcast 192.168.255.255
Armini: netmask 0xffff0000 broadcast 192.168.255.255
Panda: netmask 0xffffff00 broadcast 192.168.1.255
Iyonix: netmask 0xffffff00 broadcast 192.168.1.255

The machines with the same netmasks and broadcast adresses can work together.

0xffff0000 = 255.255.0.0
0xffffff00 = 255.255.255.0

It’s all very well for those who understand this – there is very little documentation. The A9home would not work with too much broadcast traffic requiring switches rather than hubs so I assumed that netmask just cut out unwanted broadcasts specifying a 255 where that element of the address was constant. Anyway thanks for the help it now works OK. I just wish I had asked a year ago!!

It’s all very well for those who understand this – there is very little documentation.

Well you could look at the wikipedia item but I think this is better: http://www.tcpipguide.com/free/t_IPDefaultSubnetMasksForAddressClassesABandC.htm

Anyway thanks for the help it now works OK. I just wish I had asked a year ago!!

Which sort of takes us back to the start of the thread where Dave asked whether the subnet masks were the same on all machines and whether there was a firewall. Then I commented about it being best to check.

As Wouter has pointed out the broadcast address for one group is 192.168.255.255 and the other is 192.168.1.255. Simply put the mask does what is says to the masked element of the address so the effective address “seen” is 255.255 in one case and 255 in the other.
That 192.168.1 or 192.168.255 is your social group so to speak. Hence the habit of talking about 192.168.y.x or 192.168.1.x where x is the same in both cases but they aren’t in the same network, unless y = 1 but even then the communication is flakey.

Chris: Re IfConfig: kvm_nlist(): Unimplemented SWI
on VRPC you could try under Windows at the cmd prompt:

ipconfig /all

It should give you a fuller list of PCs address, mask etc which presumably is the what VRPC will be using.

Chris Hall Wrote:
How does ShareFS recognise remote computers that have a shared disc so that it can add them to Resources:$.Discs? I have several computers on a network, including Iyonix and VRPC (both of which have a drive that is shared) but my Panda can only see one and my Pi can only see the other. If I swop over their network connections (Panda and Pi), they can still only see the share they saw before. There must be a simple solution!!

On my thread in comp.sys.networking “ShareFS (Was Re:HostFS)” Tony Moore posted a solution today that completely solved my ShareFS problem.

A RPCemu install on one machine that couldn’t be seen on the LAN by any of the other RO installs on other machines.
Similarly a VRPC-Adjust SA install on one machine that couldn’t be seen on the LAN by any of the other RO installs.

After implementing Tony’s solution on both the RPCEmu and VRPC installs, all RO machine on the LAN can now see and communicate with each other via ShareFS.

Also worth noting, the VRPC install Fay has on her Win PC couldn’t be seen by any other RO install, but again using Tony’s solution, now it can.

Apologies, a bit missing from my posting.

It should have been… “comp.sys.acorn.networking”

Apologies, a bit missing from my posting.

It would be nice if the info for both solutions (they were different faults¹) was available in the same place. I’ve added a comment about subnet masks needing to be the same to the c.s.a.n thread.

¹ Chris had an issue with differing subnet masks which effectively made the four machines sit in two different networks (easily done) and IUC you needed a sharefswindow setting modification.

My original question has not been answered fully. ShareFS will show a remote computer in Resources:$.Discs if it receives a broadcast message from the remote computer. After this you can do a ‘Save Mounts’ and the icon for the remote computer will always be there, greyed out if it doesn’t receive a broadcast message or ‘disappears’. How do you put a remote computer that you know exists, but is currently switched off, into the place whewre ‘save mounts’ would expect to put it so that it will appear, albeit greyed out?

I’d be very surprised if that is possible as such but presumably could be hacked somehow, but why not just turn the remote system on, set it and turn if off?

How do you put a remote computer that you know exists, but is currently switched off, into the place whewre ‘save mounts’ would expect to put it so that it will appear, albeit greyed out?

Bytes 80-106 in the CMOS are for Access and hold details of saved Shares, so theoretically you could hand-edit your CMOS settings (remember to change the final check digit too) to include the name of the share you wished to add. Presumably OS_Byte 162 would do the job for you.