[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MacGate Revival
On Saturday, May 25, 2013 2:27:07 PM UTC-5, Miles Lott wrote:
> On Saturday, May 25, 2013 6:29:09 AM UTC-5, Miles Lott wrote:
>
> > On Saturday, May 25, 2013 6:20:02 AM UTC-5, Miles Lott wrote:
>
> >
>
> > > On Friday, May 24, 2013 2:58:04 PM UTC-5, Lisa2dotcom wrote:
>
> >
>
> > >
>
> >
>
> > > > 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.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Rick
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > 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.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > 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.
>
> >
>
> >
>
> >
>
> > 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.
>
>
>
> 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
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.. ...!