5.19 ROM, 24-Jul-12

Can now save the share on re-boots – excellent but the Share availability is sometimes intermittent requiring further re-boots. Very reliable on previous ROMs. Has anything changed? Are others finding this?

Access to MicroSD card is excellent – makes doing software upgrades a lot simpler. Thanks to the ROOL team for implementing this excellent facility.

What machine is this on?

For the past week or two I’ve been encountering the ShareFS issue you describe on a Pi. ShareFS always seems to detect my Iyonix’s share OK, but won’t always communicate with it (always times out), requiring a reboot. Netsurf, etc. seems to work fine, so it doesn’t look like it’s an issue with networking in general. And if you’re on an OMAP machine, then that would rule out the last set of changes I made to the Pi USB driver. Which would then leave my ShareFS zero page fixes, or the DHCP changes.

(I was hoping someone else would spot the issue and fix it before I end up looking into it!)

Silly me, a BB -xM. Sorry about that.

So there could be an issue. Once up and running (active Share icons on Iyonix and BB) I haven’t noticed any time-out when pushing data from the Iyonix to BB so far but I haven’t tested it thoroughly. Good luck with a fix.

Jeffrey could you tell me if the new Time and date (neat icon by the way) in Boot.Configuration “Set from network” actually works. I did have a look at it but can’t get it to work.

I don’t know if this is related, but if I share a disk from my Beagle and my Pi, only one can be accessed from the Iyonix and they can’t see each other. (Is this MAC related maybe, even though they obtain different IP’s from my router?)

In response to Jeffrey:
I have seen the same intermittent issue – sometimes the visibility of an RPC share not visible on the BB-xM, other times the share appears to time out.

To follow on from Tanks comment – the IP address is just a means for a machine with one MAC to decide where to send packets to another machine with a different MAC, once the MAC is known at each end its all machine id to machine id (L2) if the OMAP based machine doesn’t have a defined MAC you are reliant on an age out of the MAC after the machine disappears or a re-ARP to establish the correct new MAC. After all machines don’t normally use a random MAC each time they boot.

While on the subject of 5.19 July 24th build peculiarities I have a FAT32 boot with a FAT32 SD ROM and U-boot build which immediately after boot shows a hybrid of the SD and memory stick (SCSIFS) content when SD is selected and shows the content of $.!Boot while claiming the directory is $. when SCSIFS is selected.

close the directory and click again on either disc and the correct content is shown.

I thought I’d do the FAT32 on both as it’s the most convenient build and is likely to be used by many newcomers so some sucker/volunteer needs to test things.

Here’s something interesting: Because I was having difficulty finding a reliable way of reproducing the ShareFS problems, I wrote a test script that I could leave running to check for the issue. Nothing complex – just wait a couple of minutes after entering the desktop (to make sure the share has been found), then try accessing the share, log the result, and reboot.

After leaving it running overnight I checked the log file in the morning, and found that the issue occurs precisely every 1 in 9 times the machine is restarted – one failure followed by eight successes, with no deviation.

…I wrote a test script that I could leave running to check for the issue.

After leaving it running overnight I checked the log file in the morning, and found that the issue occurs precisely every 1 in 9 times the machine is restarted – one failure followed by eight successes, with no deviation.

Curiousity: Time related, or some unknown boot count marker?
Alter the time of the loop? Force an odd number of minutes between reboots, like 11 minutes as it’s not near a binary power, but still small enough to give sizable repeats over a 12 hour period.

Curiousity: Time related, or some unknown boot count marker?

Time related, it would seem. After changing the script to try accessing the share as soon as it’s detected (and consequently resetting the machine more often), the failure rate dropped to 6 in 207. Except it can’t be the clients time that’s causing the issue, as my Pi doesn’t have a clock or nettime set up!

Reverting to the version of Freeway before Rik changed it to assign 10.×.×.x IP addresses instead of 1.×.×.x seems to fix the issue. So now I just need to work out why it’s failing, since the interface clearly shouldn’t be using the autoassigned IP once DHCP has completed. It wouldn’t surprise me if part of the problem is that my home network is using the 10.×.×.x subnet, so packets which would have previously been discarded by either the router or the Pi are now getting through OK, and then somewhere along the line something is caching the fake address and not adapting once the proper one is assigned.

If you do a *Configure FreewayAutoAddress Off, then Freeway won’t assign any IP address when it starts up.

Time related, it would seem. After changing the script to try accessing the share as soon as it’s detected (and consequently resetting the machine more often), the failure rate dropped to 6 in 207. Except it can’t be the clients time that’s causing the issue, as my Pi doesn’t have a clock or nettime set up!

Seed value for the random MAC or something similar?

Reverting to the version of Freeway before Rik changed it to assign 10.×.×.x IP addresses instead of 1.×.×.x seems to fix the issue. So now I just need to work out why it’s failing, since the interface clearly shouldn’t be using the autoassigned IP once DHCP has completed.

I’ve never looked at the function of the Freeway module, but Wireshark capture of the packets issued by the device with the original 1.×.×.x config and the newer 10.×.×.x config should show any differences.

Hmmm, a quick capture of the local network filtering out my local host seems to show a simple UDP broadcast on port 32770 – Protocol/Name: filenet-nch with no embedded IP in the 1.×.×.x range. Two packets advertising the machine name and share name on that source IP.
However although I ran a quick file transfer there is no captured non-broadcast traffic. To pick up all traffic I need to mirror the whole traffic stream out to my capture station.

Seed value for the random MAC or something similar?

The “random” MAC used with the SMSC driver in EtherUSB isn’t random. And neither is the IP address Freeway assigns to interfaces.

My next step will probably be to look at the ShareFS source, and add/enable some debug output so I can see what it’s doing. That way we can work out if it’s ShareFS being silly or something else (most likely ShareFS, since other networking doesn’t seem to be affected by the issue)

The “random” MAC used with the SMSC driver in EtherUSB isn’t random.

For a beagleboard would you expect the same MAC presented, and if not on what basis is the MAC that is presented derived?

My experience is a different MAC on each reboot, random or pseudo-random.

For a beagleboard would you expect the same MAC presented

Yes.

My experience is a different MAC on each reboot, random or pseudo-random.

Which version of EtherUSB are you using? The version in CVS uses fill_arbitrary_MAC to set the MAC, which (with EtherUSB in ROM) means it’ll always use the same MAC due to EtherUSB$MAC_Configured not being set.

My experience is a different MAC on each reboot, random or pseudo-random.

Oh God. Please no. My Livebox will have a nervous breakdown!

(it remembers connected devices by MAC address; even if I switch off the thing to only allow known MACs, it will still try to remember that device-with-this-address-connected)

Panic not Rick, my previous comment

My experience is a different MAC on each reboot, random or pseudo-random.

is not true for my current install (Aug 7 rom) and it gives the same default MAC.

Oh God. Please no. My Livebox will have a nervous breakdown!
(it remembers connected devices by MAC address; even if I switch off the thing to only allow known MACs, it will still try to remember that device-with-this-address-connected)

Could be fun if you have two beagleboards operating on the default MAC.
Any handy documentation on setting the EtherUSB$MAC_Configured variable etc to produce a unique MAC?

Any handy documentation on setting the EtherUSB$MAC_Configured variable etc to produce a unique MAC?

If you know which MAC you want to use, you can use this technique to make sure it’s applied on boot.

I’ve finally got to the bottom of the problem with ShareFS: it’s this bug in the TCP/IP stack, where old routes don’t get cleaned up properly when an interface has its address changed. This leads to sent packets having the wrong ‘from’ address, and consequently any response the recipient sends gets lost.

I’ve tracked down the fixes (for FreeBSD 4.x) in their CVS, and it looks like it should be fairly straightforward to apply them to our code. However it does mean pulling in a couple of new functions which must have been added some time after Acorn took the copy they used for Internet 5, so don’t be surprised if something else breaks in response.

Great work Jeffrey, what were the symptoms of this particular bug?
There have been recent reports of ShareFS problems when DHCP enabled, was it that one?
As it sounds like a long standing one I guess not. If not presumably RiscPCs etc can take advantage of the fix. Will there be a softloadable version for users of RISC OS 3.70 / 4.02 etc?

Great work Jeffrey, what were the symptoms of this particular bug?
There have been recent reports of ShareFS problems when DHCP enabled, was it that one?

Yes, ShareFS was the most obvious thing that showed problems. I think the only time the bug would cause problems would be if an interface changes IP address but remains on the same subnet, and if there had previously been some successful communication using the old address (e.g. ShareFS sending/receiving some packets before DHCP kicks in).

Previously this would have been a rare occurence, but a recent change in Freeway means that anyone who has their home network on the 10.×.×.x subnet will have started seeing the issue.

Will there be a softloadable version for users of RISC OS 3.70 / 4.02 etc?

I can’t think of any reason why not. However it might take me a while to get round to putting it together!

Also, the fixes are now in the latest ROMs. should be in tomorrow’s ROMs.

Also, the fixes are now in the latest ROMs

Isn’t that “Will be in the ROMs when a build occurs”?
as the commit was on the 26th and there appears to have been no autobuild this morning (27th).

Bank Holiday for autobuilders :-)

Yes – quite right. I thought today was the 26th, so when I checked the downloads page I thought there were new ROMs there. Hopefully they’ll turn up tomorrow!

How do we check the MD5sum of a ROM on RISC OS? I have done this for tarballs, and have downloaded CoreUtils in the hope of using that to read the MD5sum for zip files (that are advertised as having a md5sum), but I get a segmentation fault :-((
OK, it seems to need Alignment Exceptions Off. I have just checked a MD5sum on a ROOL ROM zip file and it works, agreeing with the published string. :-))
By the way, it gives an ‘MD5sum’ for, it seems, any file! I just tried it on a text file that I created and it gave a checksum for it. Is my Beagle behaving normally, or is this deviant behaviour?

The autobuilder ran just fine on Mon am but the upload from there to the web server took an unusually long time and just missed the cron job which then puts everything onto our downloads pages and updates the md5sums. I manually updated our site tonight with the Monday builds but everything should be fine again tomorrow (I moved the cron job back 30 minutes to 9am UK time so this shouldn’t happen again – for a while).

I reckon the ever-increasing size of various builds and number of builds are the reasons why the transmit from autobuild server to web server takes longer and longer, meaning I’ll occasionally have to make these adjustments (or make the system smarter and act of a “finished transfer” flag rather than a fixed-time cron job). Yet another thing for the never-ending ToDo list…