[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MacGate Revival
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.