Econet to AUN bridge on Raspberry Pi - released

[davehill]

What are the Unix-level permissions on the top-level directory that the fileserver users (the one in your econet.cfg for the fileserver in question) ?

Please can you perhaps post a 'ls -la' in that directory?

Edit: also, please can you post the bridge output when you create two new users in succession (ensuring you aren't using the '-f' switch on the bridge), and then another 'ls -la'?

Ta

C.

Code: Select all

root@raspberrypi:/econet# ls -la
total 40
drwxrwxrwx  4 root root 4096 May 11 17:42 .
drwxr-xr-x 22 root root 4096 Apr  5 20:38 ..
drwxr-xr-x  8 root root 4096 May 11 17:41 0ECONET
drwxr-xr-x  2 root root 4096 Apr 13 15:21 1STORAGE
-rwxrwxrwx  1 root root  256 May 10 17:32 Configuration
-rwxrwxrwx  1 root root 2560 Apr 21 19:07 Groups
-rw-r--r--  1 root root  256 May 11 17:42 Passwords
-rw-r--r--  1 root root 1536 May 10 19:02 Passwords.old

Code: Select all

[+       0.127000]    FS: Server 0 successfully initialized
NET STN    FD WHERE TYPE HOST                           PORT# SERVER
  9                      LOCAL NETWORK
128                      DEFAULT FARSIDE BRIDGE NETWORK
 99                      DYNAMICALLY ALLOCATED STATION NETWORK
  0   1     4 Wire  AUN                                 32765       
  0   3     6 Wire  AUN                                 32767       
  0   6     5 Wire  AUN                                 32769       
  0 254     8 Local AUN                                 32768 F     /econet 
128  81       Dist. AUN  192.168.1.81                   32801       
128 168       Dist. AUN  192.168.1.168                  32802       
[+      10.256000]    FS:                         Ejecting station  99.  1
[+      10.260000]    FS:            from  99.  1 Login as SYST      , index 0, id 0, disc 0, URD $, CWD $, LIB $.Library, priv 0x80
[+      10.264000]    FS:            from  99.  1 Read Discs from 0 (up to 14)
[+      10.265000]    FS:            from  99.  1 Read Discs from 2 (up to 14)
[+      10.268000]    FS:            from  99.  1 Read Discs from 0 (up to 30)
[+      10.274000]    FS:            from  99.  1 Opened handle 4 (:ECONET.$.ArthurLib)
[+      10.275000]    FS:            from  99.  1 Close handle 3 (:ECONET.$.Library)
[+      15.600000]    FS:            from  99.  1 Create new user dave
[+      19.478001]    FS:            from  99.  1 Create new user test
[+      25.608000]    FS:            from  99.  1 Login attempt - username 'DAVE      ' - Unknown user
[+      30.827999]    FS:            from  99.  1 Login attempt - username 'TEST      ' - Unknown user

Code: Select all

root@raspberrypi:/econet# ls -la
total 40
drwxrwxrwx  4 root root 4096 May 11 17:42 .
drwxr-xr-x 22 root root 4096 Apr  5 20:38 ..
drwxr-xr-x  8 root root 4096 May 11 17:41 0ECONET
drwxr-xr-x  2 root root 4096 Apr 13 15:21 1STORAGE
-rwxrwxrwx  1 root root  256 May 10 17:32 Configuration
-rwxrwxrwx  1 root root 2560 Apr 21 19:07 Groups
-rw-r--r--  1 root root  256 May 11 17:42 Passwords
-rw-r--r--  1 root root 1536 May 10 19:02 Passwords.old

I tried changing the permissions on the password file. Didnt seem to help.

[cr12925]

I tried changing the permissions on the password file. Didnt seem to help.

Are you running the bridge as root??

[davehill]

I tried changing the permissions on the password file. Didnt seem to help.

Are you running the bridge as root??

Yes, I have also tried as the pi user

[cr12925]

I tried changing the permissions on the password file. Didnt seem to help.

Are you running the bridge as root??

Yes, I have also tried as the pi user

Is the directory listing you provided after adding the new users? If so, it looks like for some reason the bridge isn't managing to write out the extended password file.

Edit: You've provided two. I assume the latter is after creating the new users, and the password file in it is still 256 bytes, which is only one user.

C.

[IanJeffray]

- The kernel module now attempts to auto-detect what hardware it is on, and write to the correct peripheral base register without it having to be defined. Those using Pi3s and PiZero2s should now be able to do a straight pull, recompiled & reinstall. (I have only been able to test this on Pi4B & Pi3B but am hopeful it will be fine on other platforms. Please let me know!).

Works fine on Pi4 (v1 hw) and Pi3 (v2 hw). For shiggles I tried v2 hw on Pi2...

[ 8.866091] ECONET-GPIO: Peripheral base address set to 0xFE000000

econet-bridge runs, but doesn't appear as a station on the bus, and econet-monitor sees nada happening.

[cr12925]

- The kernel module now attempts to auto-detect what hardware it is on, and write to the correct peripheral base register without it having to be defined. Those using Pi3s and PiZero2s should now be able to do a straight pull, recompiled & reinstall. (I have only been able to test this on Pi4B & Pi3B but am hopeful it will be fine on other platforms. Please let me know!).

Works fine on Pi4 (v1 hw) and Pi3 (v2 hw). For shiggles I tried v2 hw on Pi2...

[ 8.866091] ECONET-GPIO: Peripheral base address set to 0xFE000000

econet-bridge runs, but doesn't appear as a station on the bus, and econet-monitor sees nada happening.

Yes, that'll be because I didn't put the compatibility string in for a Pi2 on the basis that I suspected it wouldn't be powerful enough! I should perhaps make the module refuse to load! If you want to add it, have a look in the module source code and find the series of if..else if statements which include the calls to of_machine_is_compatible(), and stick an extra clause in which looks for "raspberrypi,2-model-b", and another for "raspberrypi,2-model-b-rev2" (which is the 2710-based one). Not quite sure what the right base address is for those though. Then recompile, reload, etc. ...

Best

C.

[davehill]

Are you running the bridge as root??

Yes, I have also tried as the pi user

Is the directory listing you provided after adding the new users? If so, it looks like for some reason the bridge isn't managing to write out the extended password file.

Edit: You've provided two. I assume the latter is after creating the new users, and the password file in it is still 256 bytes, which is only one user.

C.

Yes, the first is before the new users and the second is after the new users. I set the permissions RWX for everything. Not sure what else I can do?

[IanJeffray]

... I didn't put the compatibility string in for a Pi2 on the basis that I suspected it wouldn't be powerful enough! I should perhaps make the module refuse to load!

Refusing to load on "known useless hosts" would definitely be a good plan, but I thought the Pi2 was similar power to a PiZero (original Zero, not 2, not W)...

She's running just fine, it seems!

[cr12925]

... I didn't put the compatibility string in for a Pi2 on the basis that I suspected it wouldn't be powerful enough! I should perhaps make the module refuse to load!

Refusing to load on "known useless hosts" would definitely be a good plan, but I thought the Pi2 was similar power to a PiZero (original Zero, not 2, not W)...

IMG_E0962.JPG

She's running just fine, it seems!

Is that a v2 board on an original pi zero??!

[IanJeffray]

Is that a v2 board on an original pi zero??!

Yes, and it's been serving an A3020 running the BeebMaster test flawlessly for over 30mins now (Whilst the Compact simultaneously is running the test against a Pi4/v1 hardware on the same Econet).

[cr12925]

Is that a v2 board on an original pi zero??!

Yes, and it's been serving an A3020 running the BeebMaster test flawlessly for over 30mins now (Whilst the Compact simultaneously is running the test against a Pi4/v1 hardware on the same Econet).

That’s most encouraging!

[KenLowe]

- The kernel module now attempts to auto-detect what hardware it is on, and write to the correct peripheral base register without it having to be defined. Those using Pi3s and PiZero2s should now be able to do a straight pull, recompiled & reinstall. (I have only been able to test this on Pi4B & Pi3B but am hopeful it will be fine on other platforms. Please let me know!).

Cool . I no longer need to hunt for, and modify, the gpioreg.h file every time I switch between Pi models.

If I take my SD card from one Pi model to another, do I still need to recompile? An initial test seemed to indicate that was the case, but I might have been doing something wrong. It would be nice if the Pi model could be determined at run time avoiding the need for a recompile.

Is that a v2 board on an original pi zero??!

Yes, and it's been serving an A3020 running the BeebMaster test flawlessly for over 30mins now (Whilst the Compact simultaneously is running the test against a Pi4/v1 hardware on the same Econet).

That’s most encouraging!

Confirming that I also have a Pi Zero W running successfully on a v2 board! I'm seeing a few messages like this in the dmesg log, but it doesn't seem to be affecting the clobber test which is currently just over pass 200 with 0 network and 0 data errors :

Code: Select all

[May11 22:22] ECONET-GPIO: econet_irq_read(): RX Abort received at ptr = 0x03
[ +22.660540] ECONET-GPIO: econet_irq_write(): TX Underrun at byte 01 - abort transmission

[cr12925]

Cool . I no longer need to hunt for, and modify, the gpioreg.h file every time I switch between Pi models.

If I take my SD card from one Pi model to another, do I still need to recompile? An initial test seemed to indicate that was the case, but I might have been doing something wrong. It would be nice if the Pi model could be determined at run time avoiding the need for a recompile.

Code: Select all

[May11 22:22] ECONET-GPIO: econet_irq_read(): RX Abort received at ptr = 0x03
[ +22.660540] ECONET-GPIO: econet_irq_write(): TX Underrun at byte 01 - abort transmission

Yes you’ll need a recompile because the kernel is built slightly differently on the different models.

Not sure about the aborts - a zero is probably on the edge performance-wise, but the upper layer protocol should hopefully recover…

C

[davehill]

Yes, I have also tried as the pi user

Is the directory listing you provided after adding the new users? If so, it looks like for some reason the bridge isn't managing to write out the extended password file.

Edit: You've provided two. I assume the latter is after creating the new users, and the password file in it is still 256 bytes, which is only one user.

C.

Yes, the first is before the new users and the second is after the new users. I set the permissions RWX for everything. Not sure what else I can do?

Okay, I figured it out, and it appears I have been somewhat dumb... I was creating the users in lowercase instead of using uppercase!! DOH!!

[BeebMaster]

The file server should treat all commands sent to it in lower case or upper case or a mixture, as the same (this actually is a problem with the old Level 1 file server which only accepts upper case commands, so autobooting from a Master doesn't work as ANFS sends "*i . boot"!) so I would venture to suggest that's a bug.

[IanJeffray]

The file server should treat all commands sent to it in lower case or upper case or a mixture, as the same (this actually is a problem with the old Level 1 file server which only accepts upper case commands, so autobooting from a Master doesn't work as ANFS sends "*i . boot"!) so I would venture to suggest that's a bug.

I previously reported this

[cr12925]

The file server should treat all commands sent to it in lower case or upper case or a mixture, as the same (this actually is a problem with the old Level 1 file server which only accepts upper case commands, so autobooting from a Master doesn't work as ANFS sends "*i . boot"!) so I would venture to suggest that's a bug.

I previously reported this

I think it does this - though it didn't recognize lower case usernames. I have just pushed a version which does.

Are passwords meant to be case insensitive as well??

Latest push also allows tweaking of certain timeouts (see -h option, and the updated README).

Going to work on some final items now, which include:

• 64 bit kernel compatibility
• Code cleanup, especially the kernel module
• *LOAD/SAVE parsing (incl. abbreviations) for Aton
• Abbreviated command parsing generally
• Long filenames
• More of the SJ printer control
• Logic for second interface
• Threading

C.

[cr12925]

@BeebMaster - re arbitrary filename lengths.

Isn't there a problem with fs examine with arg=0, where the reply packet has a fixed 10 character space for the filename?

best

C.

[BeebMaster]

Yes, with that call the filename will be truncated to 10 characters if longer. But other calls do send the whole filename, even if longer, and even if the length byte preceding the filename is 10.

*CAT and *EX will display the full filenames so they must use a different call to get the information.

[BeebMaster]

I think it looks like CAT uses arg=3, filename and access string, and EX uses arg=1, all info as string, as they do work.

I will post some test examples & situations over the weekend. Possibly a new thread on the subject of long filenames generally might be good for this.

[cr12925]

I think it looks like CAT uses arg=3, filename and access string, and EX uses arg=1, all info as string, as they do work.

I will post some test examples & situations over the weekend. Possibly a new thread on the subject of long filenames generally might be good for this.

Yes, I think that might be wise!

[IanJeffray]

Possibly a new thread on the subject of long filenames generally might be good for this.

Yeah. Because it took me "forever" to figure out that was why some files I was putting on the server from the Linux side were just mysteriously missing from the Econet view. That, and using characters that Econet apparently can't support (foo.zip just "magically" disappears... kinda unfriendly). Adding some kind of filename fudging layer would be great.

[cr12925]

Possibly a new thread on the subject of long filenames generally might be good for this.

Yeah. Because it took me "forever" to figure out that was why some files I was putting on the server from the Linux side were just mysteriously missing from the Econet view. That, and using characters that Econet apparently can't support (foo.zip just "magically" disappears... kinda unfriendly). Adding some kind of filename fudging layer would be great.

Ah - well, there is already quite a bit of 'fudging' going on under the hood!

To do it scalably, it would probably look pretty horrid:

- There wouldn't be a reliable way of shortening a long filename, so one unique way of doing it would be to present such a file as 'LONGABCDEF' where 'ABCDEF' is the inode number. But even that could cause problems with a matching acorn filename that happens to turn out the same.

- Where '.'s are concerned, I'd need to find another beeb-character to map to them. They aren't permitted in Econet filenames (hence they don't show up) but I am not sure there is another character spare I can use. I would prefer a one-to-one mapping of '.' on the unix side to something on the acorn side, but I think everything else is used. I suppose I could present them as 'DOTABCDEF' with the same scheme as for long filenames, but it would have the same problem.

Whilst the PiFS uses the linux filesystem layer to store things, in truth I didn't design it to have files plopped into the filesystem other than by being put there by the fileserver. The halfway house might be to create a script that would be cron-able that would scan & report on incompatible filenames in the directory structure of the PiFS by, for example, creating a file accessible as %Incompat which contained a list? (% files in PiFS are stored outside the acorn-accessible hierarchy, so the incompat file would in truth be in the folder that the disc directories are created in.)

Best

C.

[cr12925]

I think it looks like CAT uses arg=3, filename and access string, and EX uses arg=1, all info as string, as they do work.

I will post some test examples & situations over the weekend. Possibly a new thread on the subject of long filenames generally might be good for this.

Yes, but I think RiscOS makes much more use of arg=0... (hence some furious bugfixing a while back!)

C.

[wiggy]

- Where '.'s are concerned, I'd need to find another beeb-character to map to them. They aren't permitted in Econet filenames (hence they don't show up) but I am not sure there is another character spare I can use. I would prefer a one-to-one mapping of '.' on the unix side to something on the acorn side, but I think everything else is used. I suppose I could present them as 'DOTABCDEF' with the same scheme as for long filenames, but it would have the same problem.

The RISC OS rule-of-thumb is to swap '.' and '/' - obviously this is being done in one direction already to make directory separators work, so the symmetry makes a kind of sense.

Thus if you view a DOS floppy on RO, for example, the DOS files appear along the lines of "FOO/ZIP" and "README/TXT". I'm fairly sure the RO NFS implementation does the same.

[BeebMaster]

Established convention for filename mapping is here:

https://beebwiki.mdfs.net/Filename_character_mapping

[cr12925]

- Where '.'s are concerned, I'd need to find another beeb-character to map to them. They aren't permitted in Econet filenames (hence they don't show up) but I am not sure there is another character spare I can use. I would prefer a one-to-one mapping of '.' on the unix side to something on the acorn side, but I think everything else is used. I suppose I could present them as 'DOTABCDEF' with the same scheme as for long filenames, but it would have the same problem.

The RISC OS rule-of-thumb is to swap '.' and '/' - obviously this is being done in one direction already to make directory separators work, so the symmetry makes a kind of sense.

Thus if you view a DOS floppy on RO, for example, the DOS files appear along the lines of "FOO/ZIP" and "README/TXT". I'm fairly sure the RO NFS implementation does the same.

At the moment, the only mapping the FS does is '/' in BBC world maps to ':' in Unix world. I can change that to '.', and then make the wildcard normalize routine just ignore '.inf' files where there is a matching file with the same basename...?

C.

[cr12925]

Ok, today's update features a new command line parser which deals properly with abbreviations (e.g. *DELE., *ACC.), and implements *LOAD / *SAVE parsing for Atoms.

[KenLowe]

I've managed to get the Pi to generate the 8MHz clock for the ADLC circuit, and the 200kHz / 20% Duty Cycle clock for the Econet network. Details here:

viewtopic.php?p=358809#p358809

8 MHz clock for ADLC circuit (divided down to 2 MHz in hardware)


200kHz Econet clock - 5uS Period / 1uS Mark


Next up, I'll need to:

• wire the Econet clock into a differential line driver, and test that on a real network in place of the beebmaster clock. I'll also need to add suitable termination, because the BeebMaster style termination will not compatible.
• switch out the onboard 8MHz hardware clock and replace it with the Pi version instead, and give that a test.

I'll get onto those tests at the weekend.

[cr12925]

I’ll try and fix the module bug on the 8MHz - we really need that running before the module trues to use the adlc - which coukd be during boot with a v2 board with a populated eeprom.

The network clock via gpio18 on a v2 board (v1 uses it for something else) can sensibly be by script - but obv less helpful if network may be in use whilst pi is off / rebooting!

Best

C