MacGate Revival

[Miles Lott]

Hello, all. I am new to the group and have only been working with Apple 2's since January. Hopefully this is the right place to post this.

Anyway, I am working with a IIGS connected to A2SERVER using the supplied VM. Thanks to Geoff I got localtalk working through a Farallon PN848.

I found some older code for MacGate and have managed to update the code to the point that it compiles cleanly and runs in the VM (Ubuntu with kernel 3.5.0). MacGate is supposed to be an appletalk to TCP/IP gateway and/or router.

The IIGS connects to the network and finds the gateway using MacIP with Marinetti 3.X installed. However, this is currently the extent of my success with this and neither Telnet nor Casper work.

I have tried unsuccessfully to locate the original author, and I only know that he had some hand in the kernel internals for appletalk as well. So I am here to gauge interest and see if anyone is able to help with evaluating or fixing the code. I have nearly 20 years experience with Linux but relatively little experience with C.

[Antoine Vignau]

Congratulations for your work (hi Geoff) but I will not be of any help,
antoine

[Steven Hirsch]

I don't mean to belabor the obvious, but are you sure you have a telnet server
running and that the port isn't blocked by a firewall? Telnet is disabled by
default on all contemporary Linux distributions I'm familiar with.

If Casper is an ftp client (not familiar with it), same comment applies.

In the larger scheme of things, it seems like netatalk would be the obvious
place for a DDP to TCP gateway to live. I'm actually surprised that no one
ever added that feature.

Disclaimer: I am an experienced C/C++ coder with Linux system-level
programming experience. But, I have not spent a lot of time in the network
layer. Just enough to be dangerous :-).

Steve

[Miles Lott]

Yes, telnet is running on the a2server install specifically for this ;) I was able to connect to localhost and then from another linux vm, my primary file server. iptables is disabled (policy ACCEPT with no further rules).

Casper is the web server that gets installed with Marinetti on the IIGS - at least I think that was the source. So, I had expected it to be a good test to see if the the GS was listening on port 80 with that app running in the foreground.

I have done some code cleanup today, correcting types and includes and otherwise getting rid of additional warnings with -Wall still enabled. I will be able to test within an hour or so to see if that helped.

[Jonno Downes]

On Friday, May 17, 2013 7:36:15 AM UTC+10, Miles Lott wrote:
> Yes, telnet is running on the a2server install specifically for this ;) I was able to connect to localhost and then from another linux vm, my primary file server. iptables is disabled (policy ACCEPT with no further rules).
>

Can you use wireshark to confirm whether any of the telnet traffic is leaving the PN848?

[Steven Hirsch]

Excellent idea! It wouldn't be the first time a LocalTalk <--> Ethernet
bridge has caused problems. Geoff has been on ground zero for all the war
stories :-).

[Miles Lott]

tcpdump shows quite a bit of AT traffic, including:

06:55:54.078248 AT 1.146.72 > 1.105.72: at-IP 40
06:55:57.126493 AT 1.146.72 > 1.105.72: at-IP 40

...which should be the MacIP packets. The issue seems to be with the ability to actually see this traffic in MacGated. If I set the socket to listen to ETH_P_ALL then it sees plenty that it cannot decode. I added some debugging to show them but I should spend more time with that. For the socket I have tried:

// SockLT = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_LOCALTALK));
// SockLT = socket(AF_APPLETALK, SOCK_DGRAM, htons(ETH_P_ALL));
// SockLT = socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_LOCALTALK));

also htons(ETH_P_ATALK), but only the ETH_P_ALL shows anything so far. So, only the most critical parts are left to fix ;)

[Miles Lott]

Note that I am also running netatalk since that seems to be critical for nbp registration, etc. That part works fine.

[Miles Lott]

I have sent my current work to Geoff for his evaluation.

[iv...@ivanexpert.com]

Great work! I'd love to see this happen.

I've got Asante and Dayna bridges to test with as well; if you want those results, send me what you've got!

Ivan.

[Peter Neubauer]

>
> I found some older code for MacGate and have managed to update the code to the point that it compiles cleanly and runs in the VM (Ubuntu with kernel 3.5.0). MacGate is supposed to be an appletalk to TCP/IP gateway and/or router.
>

The old Debian package for MacGate contains source and a patch with a bit of documentation:

http://archive.debian.net/potato/macgate

[Miles Lott]

That is the code I am using.

[Lisa2dotcom]

Miles,
I am also keen to see this working. While I use Netatalk all the time, I was unaware that MacGate ever existed. My current MacIP gateway is a G3 iMac using IPNetRouter & System 8.6 (the last version with MacIP support). I would be glad to help do some testing when the time comes.
Rick

[Miles Lott]

So far I can see TCP packets for telnet and DNS requests from the IIGS. So, I guess the PN848 is working as is Marinetti. No response. I can telnet from A2Server to the local ip used for ipddp0. If I set a route from another machine I can get to that same ip.

Also trying to get macipgateway for FreeBSD working in another VM just to see what it does. It's also pretty old.

[Lisa2dotcom]

> So far I can see TCP packets for telnet and DNS requests from the IIGS.

Miles,
Help me understand how you can "see" the DNS requests from the IIGS? AFAIK, these requests would be Ethernet SNAP frames, containing AppleTalk packets that encapsulate the TCP/IP data (MacIP). Are you saying with Wireshark you can decode this data all the way down to the point that you know it contains properly addressed DNS requests?
Thanks,
Rick

[Miles Lott]

This is the summary when trying to connect using a hostname. .103 is the IIGS .101 is my actual DNS server, but I don't see any evidence that this reaches the LAN:

64505 2187.794859 192.168.60.103 192.168.1.101 DNS 85 Standard query A a2server.groupwhere.pri

This is an example when trying to telnet by ip address to the a2server host. 60.103 again is the IIGS. 60.1 is the ipddp0 ip address on the host:

303020 25906.889238 192.168.60.103 192.168.60.1 TCP 56 ams > telnet [SYN] Seq=0 Win=16384 Len=0

I would have expected this to NOT show up as TCP traffic as you suggested.

[sake mera]

Greet offer Free Money From Full Service Management Inc announcement, free money online! This is how to earn money online for free! Learn how to get card only 60 seconds. Cheek now http://www.mustinvestnow.com/
• No credit bureau check
• No credit card debt
• No minimum balance
• No bounced checks
Whenever the friend you've referred to us loads at least $40 to their new card, you each get a $10 credit.1
• A better way to bank
• Get paid up to 2 days faster with free3 Direct Deposit!4
• Get regular direct deposits and enjoy no-fee cash withdrawals at ACE Cash Express locations5

[Lisa2dotcom]

Miles,
But what you posted sure looks like TCP/IP traffic to me.

This is an example of a wireshark summary for a MacIP frame:

170 42.528520000 65280.232 0.255 NBP 63 Op: lookup Count: 1

In this example, my computer is trying to contact the MacIP GW to talk to the DNS server. The data inside is this:

0000 09 00 07 ff ff ff 00 00 94 b5 09 fd 00 31 aa aa .............1..
0010 03 08 00 07 80 9b 00 29 00 00 00 00 ff 00 ff e8 .......)........
0020 02 02 02 21 a0 ff 00 e8 02 00 08 31 30 2e 30 2e ...!.......10.0.
0030 31 2e 31 09 49 50 41 44 44 52 45 53 53 01 2a 1.1.IPADDRESS.*

You see in there is the address of the DNS server in plain text.

I don't think that wireshark would ever decode the source and destination IP address in the summary display for MacIP frames, its only going to show the appletalk node numbers like in my example, because they are appletalk frames that just happen to have some IP data in the payload.

Are you seeing frames like this??

I hope this helps.

[Miles Lott]

There are other frames, yes. But, I am not imagining these TCP packets, either.

Here is a SNAP packet when the IIGS is trying to connect to a2server by ip (seq number 745283):

0000 00 00 00 01 00 06 00 00 c5 35 9b 54 00 00 00 04 ........ .5.T....
0010 aa aa 03 08 00 07 80 9b 00 35 00 00 00 01 00 01 ........ .5......
0020 69 92 48 48 16 45 00 00 28 65 ac 00 00 3c 06 1f i.HH.E.. (e...<..
0030 6b c0 a8 3c 67 c0 a8 3c 01 04 0d 00 17 09 2f 10 k..<g..< ....../.
0040 ba 00 00 00 00 50 02 40 00 58 1c 00 00 .....P.@ .X...

Note c0 a8 3c 01 above (192.168.60.1). Here is seq number 745284, a unicast tcp packet:

0000 00 00 03 09 00 06 00 00 c5 35 9b 54 00 00 08 00 ........ .5.T....
0010 45 00 00 28 65 ac 00 00 3c 06 1f 6b c0 a8 3c 67 E..(e... <..k..<g
0020 c0 a8 3c 01 04 0d 00 17 09 2f 10 ba 00 00 00 00 ..<..... ./......
0030 50 02 40 00 58 1c 00 00 P.@.X...

The big AHA is that the tcp packet only appears when MacGate is running! In other words, it appears to be translating one direction but perhaps not the other. This may be progress.

[Miles Lott]

Actually, this happens when the ipddp module is loaded in decapsulation mode and the ipddp0 interface is setup with the 192.168.60.1 ip address assigned. MacGate doesn't have to be running for this much to happen.

So, the module is doing the work so far. MacGate is not doing its job yet.

[Miles Lott]

Several operations using the ipddp0 interface are not possible. It is not possible to add routes to or ping beyond the ip of the interface:

root@milosch:~/MacGate-1.15 # ifconfig ipddp0 up
SIOCSIFFLAGS: Cannot assign requested address

root@milosch:~/MacGate-1.15 # ifconfig ipddp0
ipddp0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-03-00-00-00-00-00-00-00-00-00
inet addr:192.168.60.1 Bcast:192.168.60.255 Mask:255.255.255.0
BROADCAST NOARP MULTICAST MTU:585 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@milosch:~/MacGate-1.15 # ping 192.168.60.1
PING 192.168.60.1 (192.168.60.1) 56(84) bytes of data.
64 bytes from 192.168.60.1: icmp_seq=1 ttl=64 time=0.031 ms

root@milosch:~/MacGate-1.15 # route add 192.168.60.103 dev ipddp0
SIOCADDRT: Network is down

[Miles Lott]

Setting a different hardware address on ipddp0 seems to it to be UP. It also allows for tcp responses, although those apparently still do not get back to the IIGS:

Request:

0000 00 00 03 09 00 06 00 00 c5 35 9b 54 00 00 08 00 ........ .5.T....

0010 45 00 00 28 81 fa 00 00 3c 06 03 1d c0 a8 3c 67 E..(.... <.....<g
0020 c0 a8 3c 01 04 11 00 17 0d 16 0d 60 00 00 00 00 ..<..... ...`....
0030 50 02 40 00 57 8b 00 00 P.@.W...

Response:
0000 00 04 03 09 00 06 02 02 02 02 02 02 00 00 08 00 ........ ........
0010 45 00 00 2c 00 00 40 00 40 06 41 13 c0 a8 3c 01 E..,..@. @.A...<.
0020 c0 a8 3c 67 00 17 04 11 b1 6c e2 1e 0d 16 0d 61 ..<g.... .l.....a
0030 60 12 08 84 e7 41 00 00 02 04 02 21 `....A.. ...!

[Miles Lott]

Now working on the startup portion of the software where it scans for existing ip addresses. Previously it found none but now it finds the two for a2server (ipddp0 and eth0) and the one from the IIGS, which had registered on the last run. Unfortunately, it segfaults when doing a memcpy of the ip address. I guess I need to post this somewhere:

https://sourceforge.net/p/macgated/wiki/Home/

If anyone would like to participate...

[Steven Hirsch]

On 05/28/2013 06:59 AM, Miles Lott wrote:

(BIG snip...)

>> 0030 60 12 08 84 e7 41 00 00 02 04 02 21 `....A.. ...!
>
> Now working on the startup portion of the software where it scans for
> existing ip addresses. Previously it found none but now it finds the two
> for a2server (ipddp0 and eth0) and the one from the IIGS, which had
> registered on the last run. Unfortunately, it segfaults when doing a
> memcpy of the ip address. I guess I need to post this somewhere:
>
> https://sourceforge.net/p/macgated/wiki/Home/
>
> If anyone would like to participate...

No promises, but I will try to find time to take a look.

Have you run this under a debugger?

Steve

[Miles Lott]

There is a script in there to run gdb. Since I am currently working on the startup scanner, it dies in that function with not much more information. I know it is happening at the memcpy function when trying to copy an element (ip address) from the struct returned from an nbp_lookup. This attempts to setup routes for already registered IPADDRESS and IPGATEWAY.

[Miles Lott]

I had to fix what ended up being a memory allocation problem with the startup scan.

The code now correctly checks for existing ip addresses previously registered through MacIP and seen in nbplkup. It then adds routes and starts the MacPinger program for each ip. This much I believe to be the original design. I still don't get any traffic back from the GS.

Also, if I try to register the GS after the daemon is up (disconnect/reconnect), the daemon never sees it. It is however still registered with Netatalk.