www.virtualacorn.co.uk/forum

I have recently installed VRPC-Adjust onto a new Samsung Laptop with Windows 7 Home Premium, and have found a problem with ShareFS.

ShareFS won't see other machines when VA is using the wireless adapter, only it's own shared directory is displayed, yet all other networking operations are working fine. I can ping the other acorn machines, both from VA and Windows, and even access files via Sunfish that are being served via Moonfish on an Iyonix. Internet web browsing is fine using NetSurf, in fact all networking seems fine except for ShareFS.

The strange thing is that if I use the wired adapter it works fine and shows the shares of the other machines. In fact I can start up VA with the wireless adapter and I only see the local shares, then after plugging in the ethernet cable, a few seconds later the other shares appear. So it's not like I need to re-start VA using the other network adapter to get it it work.

Both adapters are set up the same except the wired adapter is 10.0.0.38 and the wireless in 10.0.0.39. All the other settings match such as subnet mask, Gateway, DNS servers, Net Bios over TCPIP enabled.

Looking through these forums I've read similar issues talked about on the Mac version forum
http://www.virtualacorn.co.uk/forum/viewtopic.phpp=2398#p2398

But has anyone else experienced this with windows 7, and is there a fix?

Thanks for any help.
Gavin

It's not a problem that I have seen reported before, but there are several possibilities that spring to mind:

Double check the Subnet masks to ensure that both interfaces (wired and wireless) have exactly the same settings. The fault you describe can be caused if the Wireless Subnet mask is different to the other interface and the other machines on the network.

Secondly, try disabling any firewalls, it's possible that connection via the wireless isn't working as a Firewall on one of the machines, or the hadrware one built into the router) is preventing transmission.

The Subnet masks of both the wired and wireless adapters are the same at 255.255.255.0, which matches the rest of the machines on the network.

I've completely un-installed ZoneAlarm firewall and switched off Windows' own firewall.

But to add to the confusion:
After a re-start of the laptop with no ethernet cable plugged in so it is only using the wireless, I start VA. As before, all networking is fine, except for ShareFS (no remote shares are shown, and *ShareFSIcon <name> displays a faded, unmounted icon). In other words all as previously descibed in my first post.

If I then plug in the ethernet cable, after a few seconds the other shares appear, and the shared drive icon (set above with *ShareFSIcon) is mounted.

If I then UN-PLUG the ethernet cable I can still open shared discs, read and write files to the shared discs. Even the ShareFS Discs window is still active, in that changes to remote shares are mirrored when new ones appear or removed.
Therefore this is all happening via wireless and it would suggest to me that subnet masks, firwall settings are not to blame.

Gavin
(who is very baffled over this)

I would agree, I can't see it being a firewall or subnet problem.

ShareFS is a pretty poor system. All the machines on the network constantly shout at each other. If you can image a room full of people all shouting "..I'm sharing this...I'm sharing this...I'm sharing this..." adinfenitum you get some idea of the amount of network traffic even when nothing is happening.

In your case none of the shouting gets through on the wireless (to start with). Once the wired is connected the shouting gets through and RISC OS on the VirtualRPC gets the messages from the other machines. Once the messages have got through removing the wired connection allows file transfers to work and for shares to stay active.

Apart from un-necessary trafic their is one other major bug bear with ShareFS. Network interface speeds. If there are different speed network adapters on various machines running on the network ShareFS can get the right hump. Imagine some of the people in the room having their voices speeded up and others slowed down.

Given the above my best guess is that it relates to the connection speeds of the wired and wireless network interfaces. I wonder if the wired runs at the same speed as everything else, but that the wireless is a bit quicker/slower.

I think it might be worth asking RISCOS Ltd if they have any suggestions.

It's definitely a strange one!
I've even tried disabling and re-enabling the wireless adapter to see if the appearance of a 'new' network connection would wake-up ShareFS, but that doesn't work. It's as if the starting of the ShareFS protocols are tied to the wired adapter. I did wonder if it was due to installing VA while the cable was plugged in, so I tried another fresh installation while running on the wireless. but that made no difference.

I'm guessing that VA unlock code it tied to the wired adapter as that is on PCI bus 4, where as the wireless is on PCI bus6. But I don't see why that should affect the operation of ShareFS.

Regarding the speeds: the network is made up of mixed speeds. There's a Gigabit network switch, with a couple of Iyonix PCs, as well as a RPC running at 10Mbps. On the laptop running VA the wireless is 54Mbps and the wired is connected 100Mbps. But once the cable is plugged in, then removed it all works fine at 54Mbps. Even new shares appearing.

Even after rebooting RISC OS, I can still see the shares once the cable has been plugged in long enough to get things working, but I have noticed an error at boot up
net.inet.udp.checksum: Unimplemented SWI - could this be something to do with the problems?

The registration/unlocking process is unrelated to ShareFS protocols.

The only way to really work out what's happening is to stuff a packet sniffer on the wireless and see if the ShareFS messages are coming through. My best guess for the cause would be the differing speed of the wireless. ShareFS is pretty poor, you should see the appaling hooks that it has into the RISC OS Filer (shivers).

Acorn really made a mess of networking with versions of RISC OS above 3.11

The little error on startup occurs in the PreDesk sequence when a newer set of modules are softloaded on top of the ones in ROM. It's 'normal' behaviour and RISC OS 4.39 running on a 'real' RiscPC does the same when the same modules are applied.

I don't know if there is anything that might help on http://www.riscos.org in the networking guides. We can't ask the man who knew the most about RISC OS networking as he's not here.