connecting multiple users on 2 LANS - each with a router

[pSyChLoNe]

First of all the usual thank you to Ark/Morpheus for this very useful, interesting and free software.. Sincerely, hats off!

My question is the following: In theory, to connect two LANs through the internet to make them look like one, they need to a) use different address spaces but on the same subnet, and b) a successful GIT connection needs to be established between GITs on one computer only on each LAN. Right? Lets call the GIT hosts A computers, and other computers on the LANs B computers. GIT on the A computer sniffs all internal network traffic (even that not addressed to A) and forwards it to the GIT on the other A computer if its on the right port(s), which subsequently puts that packet on its network. But is GIT - in the application layer - capable of seeing packets not addressed to the host it resides on? I'm not sure, but lets assume it is.

Now what about in the case of routers in the internal network(s)? Routers/switches are smart, and only forward packets down a line if they know the destination IP of that packet resides down that line.. i.e. smart forwarding. If a B computer sends a packet, and the destination is an internal IP in the remote network, the router will be unfamiliar with that IP and will kill the packet, no? (i.e. the packet will never pass by the A computer to be detected and forwarded by GIT). If its a wireless network, each host uses a different frequency, and I guess the router never fowards packets between internal hosts unless they are addressed to each other, or broadcast packets.

So how can a B computer talk to the remote network?

Perhaps by running GIT on all the hosts (i.e. making them all A computers). Each pair of GITs would need to be connected on a different port (213, 214, etc.). Now what if a host sends a broadcast packet? Its GIT fowards it to all the GITs on the remote network, and all GITs on all internal hosts forward the same packet again to all the GITs on the remote network. Many many unavoidable duplicate sends and remote broadcasts. Are these recognized and eliminated at some lower protocol layer? If not, does GIT recognize them, or will it keep forwarding them until exponential growth of duplicates happens and *crash*?

Ark (if you've read this far and are still awake I appreciate it!) maybe on the next GIT version you could add a 'do not forward broadcast packets' option, so that GITs can be run on all internal hosts, but only one local and one remote host could be configured to forward broadcasts.

If this post was all wrong, someone please shoot me..

[Ark]

GIT sees all traffic and only looks at port numbers for filtering. Yes hubs vs switches will change what traffic is available for GIT to forward if the traffic is nonbroadcast.
I'm not sure how wireless networks work with relation to hubs vs switches, I would have assumed they operate more similar to switches probably.

GIT will not reforward back packets it has already forwarded, but yes if you have multiple GITs on LAN then you will end up with duplicate broadcast packets, and if you use hubs, not switches, you can end up with duplicate unicast packets as well. I believe it is up to the applications receiving the packets to properly discard duplicates. TCP will handle removing them for you, but UDP/ICMP do not, and the application will end up with the duplicate packets, but it should be prepared to handle duplicates since GIT is not the only thing that could potentially cause duplicates.

If you really need multiple GITs, one per computer, because you have a switch, then yes, a 'do not forward broadcast packets' option could be useful indeed. However, any *real* switch should have an option to toggle specific RJ45 jacks as 'monitor ports' so that one particular computer can see all traffic, for the explicit purpose of running a sniffer on that port (GIT is like a sniffer in this sense). Cheap switches may not offer this feature, but Cisco type swtiches usually do.

[Ark]

GIT v0.98 contains an option to not forward broadcast now.