Jump to content

AppleTalk on an Orange Pi One


op1tjaap

Recommended Posts

Having my Orange Pi One now for two weeks. 

I've compiled a new kernel with the great compile tool of Armbian.

Now I have AppleTalk as module in the kernel ( 3.4.110   -  kernel/net/appletalk/appletalk.ko)

It seems that the Ethernet device or driver does not understand AppleTalk. Although Ethernet works... well IP does. 

If I use a USB Network device (as eth1 with dm9601 module) I have no problem, but the on board network card refuses to work with the AppleTalk software Netatalk. It start, but the OrangePi dioesn't see other AppleTalk devices. With the USB network card, it works fine.

 

It is a pity, because the Orange Pi One is really the cheapest AppleTalk router in the world you could have!

 

Anyone knows what I should try to get it working? Is there an other driver I could use?

Is this network device on the Orange Pi so special?

 

Link to comment
Share on other sites

This is how it looking on a working device (NTC C.H.I.P with USB Network). Normal echo and replies.

 

 

14:04:57.790187 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.822098 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.822203 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.853084 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.853166 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.889086 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.889182 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.920095 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.920166 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.951159 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.951298 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:57.992095 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:57.992228 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.023080 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.023163 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.053079 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.053158 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.083083 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.083178 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.115077 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.115151 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.145079 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.145178 AT 65280.110.echo > 65362.173.245:  at-echo 8
14:04:58.190094 AT 65362.173.245 > 65280.110.echo:  at-echo 25
14:04:58.190193 AT 65280.110.echo > 65362.173.245:  at-echo 8
^C2866 packets captured
2925 packets received by filter
0 packets dropped by kernel
 
Al the devices:
 
root@chip:~# nbplkup
                     172.16.2.1:IPGATEWAY                          65280.110:72
   C.H.I.P. MacIPgw File Server:AFPServer                          65280.110:128
                           chip:netatalk                           65280.110:4
                           chip:Workstation                        65280.110:4
                       macuser:MacPingâ–’ 3.0.3                     65362.173:2
                     BasiliskII:AFPServer                          65362.173:250
                     172.16.2.4:IPADDRESS                          65362.173:72
                     BasiliskII:PPCToolBox                         65362.173:251
                     BasiliskII:  Macintosh                        65362.173:252
                     BasiliskII:Workstation                        65362.173:4
         vagrant-ubuntu-wily-32:netatalk                           65280.1:4
         vagrant-ubuntu-wily-32:Workstation                        65280.1:4
                          pb100:AFPServer                          65346.224:251
                          pb100:PPCToolBox                         65346.224:252
                          pb100:PowerBook 100                      65346.224:253
                          pb100:Workstation                        65346.224:4
           AsantéTalk 94081D2A:Asantâ–’Talk                         65346.223:252
 
 
This how it looks on the Orange Pi One:
 
 
 
14:06:19.263430 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:20.113264 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:20.958314 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:21.801282 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:38.343210 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:39.194084 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:40.035731 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:40.877208 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:57.360628 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:58.208601 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:59.052565 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:06:59.897943 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:17.878264 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:18.728312 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:19.574382 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:20.413621 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:36.832753 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:37.685802 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:38.528489 AT 65362.173.253 > 0.nis:  truncated-nbp 9
14:07:39.381413 AT 65362.173.253 > 0.nis:  truncated-nbp 9
 
Only the Orange Pi One to see.............
 
@orangepione:~# nbplkup
                    orangepione:netatalk                           65280.42:4
                    orangepione:Workstation                        65280.42:4
 
 
 
I see only truncated packages..... could it be that the driver we now use throws away parts of atalk packages?
Link to comment
Share on other sites

Does it work today? Already tried? Since it looks like you suffered the last 2 weeks from a simple negotiation problem:

 

 

 

[   28.730324] PHY: gmac0-0:00 - Link is Up - 10/Half
[   10.940281] PHY: gmac0-0:00 - Link is Up - 10/Half
[   12.440285] PHY: gmac0-0:00 - Link is Up - 10/Half
[   12.040284] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.940277] PHY: gmac0-0:00 - Link is Up - 10/Half
[   12.000289] PHY: gmac0-0:00 - Link is Up - 10/Half
[   12.450279] PHY: gmac0-0:00 - Link is Up - 10/Half
[   12.420292] PHY: gmac0-0:00 - Link is Up - 10/Half
[   10.970560] PHY: gmac0-0:00 - Link is Up - 10/Half
[   14.160289] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.120429] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.930271] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.720276] PHY: gmac0-0:00 - Link is Up - 10/Half
[   13.920252] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.130257] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.930255] PHY: gmac0-0:00 - Link is Up - 10/Half
[   11.340437] PHY: gmac0-0:00 - Link is Up - 10/Half

Fri Apr  1 11:17:28 UTC 2016:

[   12.650313] PHY: gmac0-0:00 - Link is Up - 100/Full
[   11.730253] PHY: gmac0-0:00 - Link is Up - 100/Full
[   10.540260] PHY: gmac0-0:00 - Link is Up - 100/Full
[   11.180269] PHY: gmac0-0:00 - Link is Up - 100/Full
[   10.990542] PHY: gmac0-0:00 - Link is Up - 100/Full
[   10.990542] PHY: gmac0-0:00 - Link is Up - 100/Full 

 

 

Link to comment
Share on other sites

Well, if it doesn't work with 100 Mbits/sec full-duplex then maybe it's really the driver's fault (written by Allwinner employees that might not even know that other protocol families than TCP/IP exist). I won't look into any of the 3.4 kernel/driver stuff any more since mainlining efforts are still progressing nicely.

 

ATM trying out mainline kernel with this branch here seems to be the best idea (still tons of RX errors but maybe this will be fixed within days/weeks also): https://github.com/wens/linux/commits/h3-emac

Link to comment
Share on other sites

Here we go:

 

You change into the dir where compile.sh and lib reside. Change into lib and do a 'git pull' to get latest changes (updated a few minutes ago extra for you). Then back into the parent directory create userpatches/linux-sunxi-dev.config with these contents. Replace the contents of lib/configuration.sh with these contents. Then do a

cp -p lib/patch/u-boot/u-boot-default/u-boot-99-opi-change-build-settings.patch userpatches/u-boot/u-boot-dev/
for file in lib/patch/kernel/sunxi-dev/*sun8i* ; do touch userpatches/kernel/sunxi-dev/${file##*/}; done

And then simply call compile.sh and choose branch dev. I successfully booted an Orange Pi PC over FEL/NFS using

./compile.sh KERNEL_ONLY=no BOARD=orangepih3 PROGRESS_DISPLAY=plain RELEASE=jessie BUILD_DESKTOP=no EXTENDED_DEBOOTSTRAP=yes ROOTFS_TYPE=fel FEL_AUTO=yes PROGRESS_LOG_TO_FILE=yes BRANCH=dev

but subsequent boot attempts always fail at NFS stage (nfs: server 192.168.83.120 not responding). Be aware: rootfs on NFS is already worst case scenario given the state of the driver ;)

 

So you might give it a try with the modifications above but be prepared that this is alpha quality. Please report back!

Link to comment
Share on other sites

LOL, you should keep in mind that the Armbian project sometimes moves a bit faster than others. Maybe 'this evening when the family is a sleep' OS images with mainine kernel will already be available in the download section (don't take this as promise, but I'm often surprised how fast we move as a team)

Link to comment
Share on other sites

OK. This version works perfect!!!

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 4.6.0-rc1-sunxi

Now also mii-tool give normal information.

#mii-tool eth0
eth0: negotiated 100baseTx-FD flow-control, link ok

Netatalk 2.2.5 is now also running fine. Just out of the box!

I put this in /etc/apt/sources:

deb http://ftp.de.debian.org/debian sid main
 

Installed netatalk

apt-get install netatalk

Put the network card in promisc mode for better exchange appletalk protocol.

Edited /etc/init.d/netatalk for starting up atalkd:

ATALKD_RUN=yes

Fired up netatalk:

/etc/init.d/netatalk start

And YES! I see all my appletalk devices!

root@orangepione:~# nbplkup
                    orangepione:netatalk                           65280.231:4
                    orangepione:Workstation                        65280.231:4
         vagrant-ubuntu-wily-32:netatalk                           65280.1:4
         vagrant-ubuntu-wily-32:Workstation                        65280.1:4
           AsantéTalk 94081D2A:Asantâ–’Talk                         65346.223:252
                       Macuser:MacPingâ–’ 3.0.3                     65362.236:2
                     BasiliskII:AFPServer                          65362.236:250
                     172.16.2.4:IPADDRESS                          65362.236:72
                     BasiliskII:PPCToolBox                         65362.236:251
                     BasiliskII:  Macintosh                        65362.236:252
                     BasiliskII:Workstation                        65362.236:4

Now the main part...... Can the Orange Pi One be the cheapest MacIP router in the world...

To get this working I need to get a kernel with ONLY appletalk as module enabled:

CONFIG_ATALK=m 

If other modules are enabled,like ddp, the kernel will intercept all MacIP traffic and it won't work. As I can see in you config you have two kernel modules enabled which will prevent macipgw to work:

CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y

These two should not be enabled. See https://github.com/zero2sixd/macipgw

 

Quote

Kernel

Your kernel must be configured with the CONFIG_IPDDP option disabled completely. It is not sufficient to compile it as a module -- in order to support the module, the kernel is modified to intercept all MacIP traffic, so userspace applications such as macipgw cannot handle it.

 

 

 

For more information about my final goal look here:

 

http://www.macip.net/

https://68kmla.org/f...ing/?hl=macipgw

 

 

 

Link to comment
Share on other sites

I don't see RX errors in the logs:

root@orangepione:/var/log# grep -i rx *
grep: apt: Is a directory
armhwinfo.log:[   20.545056] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
armhwinfo.log:          RX packets:76 errors:32 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:17754 (17.3 KiB)  TX bytes:2546 (2.4 KiB)
armhwinfo.log:          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:0 (0.0   TX bytes:0 (0.0 
armhwinfo.log:[   10.785743] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
armhwinfo.log:          RX packets:33 errors:16 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:4241 (4.1 KiB)  TX bytes:2468 (2.4 KiB)
armhwinfo.log:          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:0 (0.0   TX bytes:0 (0.0 
armhwinfo.log:[   10.746116] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
armhwinfo.log:          RX packets:43 errors:20 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:7904 (7.7 KiB)  TX bytes:2932 (2.8 KiB)
armhwinfo.log:          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
armhwinfo.log:          RX bytes:28 (28.0   TX bytes:28 (28.0 
armhwinfo.log:[   10.114884] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
armhwinfo.log:        RX packets 65  bytes 8297 (8.1 KiB)
armhwinfo.log:        RX errors 14  dropped 0  overruns 0  frame 0
armhwinfo.log:        RX packets 1  bytes 28 (28.0 
armhwinfo.log:        RX errors 0  dropped 0  overruns 0  frame 0
grep: fsck: Is a directory
kern.log:Apr  2 13:25:33 localhost kernel: [   20.545056] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kern.log:Apr  2 22:48:35 localhost kernel: [   10.785743] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kern.log:Apr  3 00:11:35 localhost kernel: [   10.746116] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kern.log:Apr  3 19:28:18 localhost kernel: [   10.114884] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
messages:Apr  2 13:25:33 localhost kernel: [   20.545056] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
messages:Apr  2 22:48:35 localhost kernel: [   10.785743] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
messages:Apr  3 00:11:35 localhost kernel: [   10.746116] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
messages:Apr  3 19:28:18 localhost kernel: [   10.114884] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
grep: ntpstats: Is a directory
syslog:Apr  2 13:25:33 localhost kernel: [   20.545056] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
syslog:Apr  2 22:48:35 localhost kernel: [   10.785743] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
syslog:Apr  3 00:11:35 localhost kernel: [   10.746116] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
syslog:Apr  3 19:28:18 localhost kernel: [   10.114884] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
grep: unattended-upgrades: Is a directory

Link to comment
Share on other sites

Hi,

 

Also made : Armbian_5.07_Orangepih3_Debian_jessie_4.6.0-rc1.zip

 

Found : No HDMI character screen, but SSH works via the standard Ethernet adapter.

 

Using 2 DVB USB tuners (TT4600 / T230), are recognized and working as expected in >4.1

Also TvHeadEnd SAT>IP is working using port 9983.

so that is indeed very good news as that is what I wanted the OrangePi for :)

 

Still to solve:

- it hangs every now and then (dead SSH, dead WEB)

- CPU usage seems a bit high, compared to RPi2

- CPU remark in dmesg, see below, is that perhaps the reason?

Will look into that tomorrow in more detail.

 

Great progress, cant wait for a final release !

 

 

[    5.390980] systemd[1]: Starting Journal Service...
[    5.397561] systemd[1]: Started Journal Service.
[    5.421201] fuse init (API version 7.24)
[    5.844342] systemd-udevd[176]: starting version 215
[    6.365875] cpu cpu0: failed to get clock: -2
[    6.365982] cpufreq-dt: probe of cpufreq-dt failed with error -2
[    6.419685] Registered IR keymap rc-empty
 

Link to comment
Share on other sites

I don't see RX errors in the logs

 

Have you checked output from '/sbin/ifconfig'? The issue is known but unresolved and you kill networking pretty reliable by doing a dual iperf test (using -d switch). But for normal usage it's already pretty stable.

 

[    6.365875] cpu cpu0: failed to get clock: -2

[    6.365982] cpufreq-dt: probe of cpufreq-dt failed with error -2

 

There is zero support for cpufreq/dvfs/thermal stuff in mainline kernel for H3 now! AFAIK the H3 is clocked with 1008MHz by u-boot and remains at this setting with mainline kernel. No throttling will occur and you can easily burn the H3 using cpuburn-a7 ATM. Please keep that in mind that there's no protection currently so in case you run heavy workloads unattended you would to either limit maximum cpufreq in u-boot (816 MHz seems somewhat safe) or disable CPU cores in case CPU utilisation increases to protect the SoC!

 

Mainline is not ready for primetime yet unless this is resolved (no idea whether someone is already working on it). The ability to build an Armbian image with kernel 4.6.0-rc* is for testing purposes only to help getting Ethernet support stable (and maybe testing other stuff like WiFi and HDMI/audio with mainline kernel)

Link to comment
Share on other sites

Understood tkaiser, it is only EUR 12 that gets fried and I am willing to take that risk. Don't worry. No production plans yet.

 

I was just very curious to see if DVB and SAT>IP worked on OPiO and it does, so I wanted to give you that feedback.

I just plan to use Orange Pi One to replace RPi2 so they can be used in other projects as they have more memory and there is more available for RPi2, so that has to wait a bit more then.

 

Thanks !

Link to comment
Share on other sites

Yup...tkaiser...you are right....ifconfig shows you the errors......

 

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.30  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 fe80::883c:1cff:fe0a:c84f  prefixlen 64  scopeid 0x20<link>
        ether 8a:3c:1c:0a:c8:4f  txqueuelen 1000  (Ethernet)
        RX packets 318355  bytes 55065352 (52.5 MiB)
        RX errors 148483  dropped 0  overruns 0  frame 0
        TX packets 74035  bytes 6355312 (6.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  base 0x4000
 
 
But no problem in keeping connected with ssh.
Link to comment
Share on other sites

But no problem in keeping connected with ssh.

 

But until 1 hour ago you were able to kill networking with rather heavy bidirectional traffic (iperf -d was already enough to kill Ethernet realiably). Fixed and worth a new checkout now: http://irclog.whitequark.org/linux-sunxi/2016-04-04#16040927;

 

But no need to since what you're planning is rather lightweight (and nice -- haven't dealt with AppleTalk maybe for over 5 years now)

Link to comment
Share on other sites

Understood tkaiser, it is only EUR 12 that gets fried and I am willing to take that risk. Don't worry. No production plans yet.

 

BTW: Two guys started working on the THS stuff in the meantime: https://github.com/megous/linux/commits/orangepi-cpufreq

 

It's reported to work already quite well on Orange Pi One (primitive GPIO regulator) but some troubles are reported with the other Oranges using the SY8106A voltage regulator accessible through I2C.

Link to comment
Share on other sites

BIG SUCCESS!!!!!!!

 

Orange Pi One is now working as a MacIPgw, a Linux MacIP gateway.

 

It is able to encapsulate IP in AppleTalk. 

I'm now able to connect all my old Macintosh computers to the Internet with the help of one Orange Pi One.

Unbelievable....... A $9,95 computer with full blown Linux OS.... Armbian!!!

 

Thanks everybody for helping me to get this far so quickly!

 

Look at the picture below. I'm surfing the Internet with Netscape 1.1 (1994/1995).

To show I'm not cheating I show the TCP/IP control panel.

 

post-965-0-44128100-1459884435_thumb.jpg

 

 

Link to comment
Share on other sites

Out of curiousity: Are your Apple devices (or simulations -- Basilisk II) really not TPC/IP capable? AFP/DDP was slow as hell. One of the greatest speed improvements I ever saw was when AppleShare Client switched automagically to TCP/IP when establishing the AFP connection after service discovery has been done using AppleTalk. Must be 20 years ago or something like that...

Link to comment
Share on other sites

Good question. To be sure I checked my afpd configuration:

"OrangePiOne" -ddp -notcp -uamlist uams_guest.so,uams_clrtxt.so,uams_dhx.so -defaultvol /etc/netatalk/AppleVolumes.default -systemvol /etc/netatalk/AppleVolumes.system -nouservol -guestname "nobody" -setuplog "default log_maxdebug /var/log/afpd.log" 

So no TCP afp possible.

The speed is acceptable. I clocked a transfer of a 7 MB file in about 2 minutes. With my PowerBook 100 with its 40 MB harddisk perfectly workable.

 

With TCP over AppleTalk it is different. That is not fast but perfectly acceptable. If you want to browse the Internet with Netacape 1.1 not many sites are available. But some telneting is perfect.

 

See some pictures of my setup. I use NSCA Telnet to login my Orange Pi One.

 

post-965-0-39430300-1460105677_thumb.jpg

 

post-965-0-09991200-1460105698_thumb.jpg

 

Link to comment
Share on other sites

TCP over AppleTalk it is different

 

 

Well, I was talking about something different (AFP over TCP instead of AppleTalk -- Apple implemented a silent switch from AppleTalk to TCP/IP in the background if possible).

 

Your pictures remind me of the situation 20 years ago. I complained to my boss back then that my 'workstation' (PowerMac 9500) was too slow. He bought then an additional 256MB RAM (for ~12500€), we used a Sun SparcStation 20 as server running EtherShare on it with a quad port Fast Ethernet card to speed up networking and data was stored on 3 RAIDs with 20GB each being loud and hot as hell.

 

And today you buy an Orange Pi One for 10 bucks, a 64 GB Samsung EVO SD card for 20 bucks and have a setup with the same storage capabilities that is magnitudes faster :)

 

At the same time I discovered a scriptable Telnet tool to interact with from AppleScript and another system extension that could generate AppleEvents so I was able to integrate Solaris and MacOS and let stuff run locally instead of transmitting large amounts of data through the wire. Funny times, we had multi CPU Macs with an operating system that wasn't SMP capable (MacOS), imposition was done on NextSTEP, one proofer was controlled by a SGI O2 (IRIX/MIPS), the other by another SparcStation running SunOS 4.x, the office people used PCs running OS/2 and we used even Windows back then: NT 3.5 on DEC Alpha workstations and later Pentium Pro...

Link to comment
Share on other sites

@tkaiser

 

Great story about your work with the PowerMac and Sun SparcStations. The world has really changed!

 

On my desk you see besides the PowerBook 100 an old Apple Lisa. This one has a 68000 5Mhz processor, 2 MB of Ram and a 10 MB harddisk. It has costed around € 15000,-

So yes also for this one. An Orange Pi One is better and cheaper!

Link to comment
Share on other sites

Time to update my MacIPpi project!

 

 

It is made better over the time and is in use now by old Macintosh users. See this excellent post in the Swedish Dator Museum (Computer Museum) about the actual use.

http://www.datormuseum.se/computers/apple/macintosh-plus

 

One bad thing about the MacIPpi is that it is still running on kernel 4.6.0 with many RX errors.

I hoped that this is fixed in Armbian 5,24 and kernel 4.9.0

I’m afraid that eth0 is working fine….no more RX errors…but NO APPLETALK!

And yes..I compiled appletalk as a module and installed Netatalk.

 

 

Is this driver for the Ethernet card now capable of running appletalk or not?

 

 

I have again the same errors as you see in this same posting.

See the errors....truncated npb is not OK.... It seems to recieve data from an other Macintsoh, but it is not understoot...

The OrangePi is also not visible for other Macintosh.

 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:10:14.684590 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:15.528220 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:16.369947 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:17.211315 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:33.462695 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:34.130278 AT 65395.129.253 > 0.nis:  nbp-lkup 24: "=:AFPServ[|atalk]
00:10:34.303273 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:34.962863 AT 65395.129.253 > 0.nis:  nbp-lkup 24: "=:AFPServ[|atalk]
00:10:35.144305 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:35.788432 AT 65395.129.253 > 0.nis:  nbp-lkup 24: "=:AFPServ[|atalk]
00:10:35.986440 AT 65395.129.253 > 0.nis:  truncated-nbp 9
00:10:36.616924 AT 65395.129.253 > 0.nis:  nbp-lkup 24: "=:AFPServ[|atalk]
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines