btr 🇪🇺

@fergycool@mastodon.social @warandpeas@mastodon.social that's what I forgot to mention: you need to modify the AppleTalk over IP extension with ResEdit, i.e. the STR resource, ID 131 needs to be set to your public IP / hostname. The extension also stores its prefs in System Folder:Preferences:mac68k.info but changing the STR value in there has no effect (looks like a bug). Username and password fields are completely ignored for now. I have a working password check implementation somewhere, but I haven't pushed it yet, pending some cleanup. Also, since it uses DES, it only gives a false sense of security (-; The other thing is the ValueError raised by Datagram.as_short_header_bytes(). I haven't yet figured out why it happens and for now I'm just changing line 118 in tashrouter/datagram.py. Instead of: raise ValueError('Invalid hop count ... ') I have: print('WARNING: invalid hop count ...') CC @smallsco@oldbytes.space

@smallsco@oldbytes.space most likely your server's address is not configured. See my reply here: https://social.cpp.org.pl/@btr/116352926049631320

@pitz@mastodon.social Technically, it's similar to LToUDP: it simply encapsulates LocalTalk frames within UDP datagrams (with some extra header data), but instead of having multiple nodes on a multicast group, we have a bunch of remote clients connecting to a single server. Initially, Dan and Paul tried to use atalkvpn as GlobalTalk base, but it was too limited. The original atalkvpn server converted LocalTalk frames to EtherTalk Phase 1, wrote them to a tap device, and was meant to be used with netatalk, which routed them to some physical ports. Since nowadays virtually nothing supports EtherTalk Phase 1 (AFAIK appletalk module for Linux never implemented it), I took a different approach and wrote a TashRouter port. This way we create a dedicated network for atalkvpn and route packets between this network and anything TashRouter supports: TashTalk, LToUDP or EtherTalk.

@billgoats canvas!

@DosFox I guess https://www.maconlinux.net/ is a good candidate

@fergycool@mastodon.social could be. When set to DEBUG, TashRouter logs the payload of each packet, effectively slowing everything down by an order of magnitude. Hope it helps!

@pitz@mastodon.social correct! atalkvpn client is an Mac OS extension, but I guess you already got this.

@pitz@mastodon.social In my current setup, I have jrouter, routing GlobalTalk networks to my ethernet, and TashRouter connecting ethernet with LToUDP and ATalkVPN. ATalkVPN is listening on my external IP, so that I can connect from anywhere. If anyone's interested, I can set up an experimental zone with a public ATalkVPN server for tests, though with a word of warning: this is alpha quality, some things aren't implemented and it will most likely freeze your Mac at some point.

@liilliil@mastodon.online jakiś czas temu napisałem blogposta: https://www.cpp.org.pl/globaltalk-siec-uzytkownikow-zabytkowych-makow/ z linkami do tutoriali. Mam nadzieję, że będzie pomocny, ale jeśli będziesz mieć wątpliwości, śmiało dawaj znać. Poza tym, rozważam wystawienie eksperymentalnego serwera atalkvpn, ale póki co, to jest dalekie od czegoś, co mogę nazwać stabilnym oprogramowaniem.

@fergycool@mastodon.social @warandpeas@mastodon.social @smallsco@oldbytes.space yup, if you're getting a timeout on the client side, it definitely sounds like a firewall/port forwarding issue. If you have your log level set at INFO or more verbose (I wouldn't recommend DEBUG though, it significantly slows things down and causes random issues), you should see something like "INFO:atalkvpn.server:Registered new node ...". This message shows if anything comes over UDP, so you can easily check if your server is reachable with netcat, e.g.: nc -zu your.atalkvpn.server.address 1029. Keep in mind that there's no client timeout mechanism implemented yet, so the client will stay registered until server restart. It shouldn't cause any issues though, it's just a tiny client object instance sitting quietly in server memory.