Morpheus Software Support Forums

It would be VERY nice GIT can also forward multicast packages.

My experience is that at this moment GIT don't recognize Multicast traffic.

If GIT does, playing a LAN game of FarCry would be possible over VPN or Internet.

THANKS

Best Regards.
Elwin Nieuwenhuis

Some tech. info:

When FarCry client does a "Refresh server list":
Src. port = 1030-3600 (dynamic range)
Dest. port = 5678 (fixed value)
Destination. IP (234.5.6.7). It looks like Dest. IP is IANA multicast.


FarCry Server:
Server respond on refresh from client.
Src. port = 49001 (fixed)
Dest port = 1030-3600 (dynamic range, same as src port sent by client)

This traffic should be forwarded, but I couldn't let GIT do the job.

There is nothing special about Multicast that prevents GIT from forwarding it. GIT will tunnel the entire ethernet frame if you tell it to pick up the proper ports.

Have you successfully played farcry through vpn ?
I've also noted that port range may be > 3000. If anyone can propose a solution for this game.
this could help but i have no bsd server :

http://www.bsdnews.org/01/game_vpn.php
http://www.j51.com/~sshay/tcpip/ip/ip.htm
http://non-standard.net/freebsd/game-vpn/game-vpn.html

I've successfully gotten FarCry to work though VPN (using Windows 2000 Server). I use GIT for Battlefield series (DC, Vietnam) and VPN for FarCry.

KaReD

Well kared, what's your're exact configuration within windows server ?
Are you using NAT ? What is you're GIT setup ? could you say more on this topic please ?

Thanks for answering.

Doesn't the strange IP 234.5.6.7 (IANA Multicast) preventing GIT from forwarding it?
Or the fact that Far Cry make use of a different source and destination port in a single request or respond?
(see my tech notes in previous message)

Ark wrote:There is nothing special about Multicast that prevents GIT from forwarding it. GIT will tunnel the entire ethernet frame if you tell it to pick up the proper ports.

ElwinOnline wrote:Thanks for answering.

Doesn't the strange IP 234.5.6.7 (IANA Multicast) preventing GIT from forwarding it?
Or the fact that Far Cry make use of a different source and destination port in a request or respond?
(see my tech notes in previous message)

Ark wrote:There is nothing special about Multicast that prevents GIT from forwarding it. GIT will tunnel the entire ethernet frame if you tell it to pick up the proper ports.

No, GIT does not care about multicast or what port is what. GIT forwards ALL traffic by just sniffing ethernet frames and reproducing them on the other side. As long as you forward ALL the ports you need using GIT, and forawrd the GIT port through your NAT if you need to, any game should work.

Ark,

Inspired by your answer I started some tests on my local LAN with the goal to check if GIT is able to pick up and forward the ethernet frames of FarCry client and server.
(The final goal is to play FarCry over VPN with some friends)

My conclusion:
The ethernet frame with the "yell" of the FarCry client isn't picked up by GIT. Sorry, but I'm absolutely sure.
The sniffer on the same machine running GIT picks up the "yell", but GIT doesn't. Really!
The clientrequest doesn't even appear in the unforwarded packets log of GIT.

At the other hand, GIT picks up and forward the respond of the FarCry server. So this part of the job works fine. (tested in another testsetup)

Please, will you give a possible explanation for this problem?

Elwin


Some tech notes of client testsetup.

PC1 (10.1.1.10):
- FarCry client is running
- GIT running in TCP listen mode (10.1.1.11:tcp listen)

PC2 (10.1.1.11):
- FarCry dedicated server
- Running GIT in TCP connection mode (10.1.1.10:tcp connect).
Forward ports 1030-3600 and port 5678
Only UDP ports, "Only if broadcast" is off
- Sniffer Ethereal

Result:
Content of sniffed ethernetframe on PC2 when PC1 does a refresh server list in FarCry:
Src IP - 10.1.1.10, Dst IP - 234.5.6.7
Src port - UDP 1124 (dynamic), Dst port - UDP 5678 (fixed)

Ark wrote:No, GIT does not care about multicast or what port is what. GIT forwards ALL traffic by just sniffing ethernet frames and reproducing them on the other side. As long as you forward ALL the ports you need using GIT, and forawrd the GIT port through your NAT if you need to, any game should work.

Here is an idea - copy one single packet from the sniffer that GIT is not picking up in any logs at all, with all of the headers, and post the hex content here.
Alternatively, write a short .C program that can generate a similar packet that a sniffer sees that GIT isn't seeing to use for testing GIT.

Ark,

Thank you for investigating this issue.
I sent you all the details of the packet, incl. hex values.
Your alternative suggestion is beyond my reach. At least it takes me to much time ;).

Elwin



No. Time Source Destination Protocol Info
1 0.000000 10.1.1.10 234.5.6.7 UDP Source port: 3583 Destination port: 5678

Frame 1 (60 bytes on wire, 60 bytes captured)
Arrival Time: Jun 10, 2004 17:51:28.455553000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:0c:6e:1a:d8:59, Dst: 01:00:5e:05:06:07
Destination: 01:00:5e:05:06:07 (01:00:5e:05:06:07)
Source: 00:0c:6e:1a:d8:59 (AsustekC_1a:d8:59)
Type: IP (0x0800)
Trailer: 0000000000000000
Internet Protocol, Src Addr: 10.1.1.10 (10.1.1.10), Dst Addr: 234.5.6.7 (234.5.6.7)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 38
Identification: 0x3961 (14689)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0x854f (correct)
Source: 10.1.1.10 (10.1.1.10)
Destination: 234.5.6.7 (234.5.6.7)
User Datagram Protocol, Src Port: 3583 (3583), Dst Port: 5678 (5678)
Source port: 3583 (3583)
Destination port: 5678 (5678)
Length: 18
Checksum: 0x162a (correct)
Data (10 bytes)

0000 01 00 5e 05 06 07 00 0c 6e 1a d8 59 08 00 45 00 ..^.....n..Y..E.
0010 00 26 39 61 00 00 01 11 85 4f 0a 01 01 0a ea 05 .&9a.....O......
0020 06 07 0d ff 16 2e 00 12 16 2a 7f ff ff ff 73 74 .........*....st
0030 61 74 75 73 00 00 00 00 00 00 00 00 atus........


-------- summary: hex only -------

01 00 5e 05 06 07 00 0c 6e 1a d8 59 08 00 45 00
00 26 39 61 00 00 01 11 85 4f 0a 01 01 0a ea 05
06 07 0d ff 16 2e 00 12 16 2a 7f ff ff ff 73 74
61 74 75 73 00 00 00 00 00 00 00 00

ElwinOnline wrote: Time to live: 1

01 00 5e 05 06 07 00 0c 6e 1a d8 59 08 00 45 00
00 26 39 61 00 00 01 11 85 4f 0a 01 01 0a ea 05
06 07 0d ff 16 2e 00 12 16 2a 7f ff ff ff 73 74
61 74 75 73 00 00 00 00 00 00 00 00

There's the problem. GIT expects a TTL of higher then 8 currently.
There is no workaround for this other then a big rewrite of how GIT handles knowing if a packet its sniffing is one it sent out itself in order to prevent an infinite loop of re-sending packets back and forth.

Damn!, I can imaging the consequences of rewriting, like the time it takes, the concentration it needs and eventually performance impact.
Well anyway, conclusion is that GIT 0.97 doesn't work with Farcry at the moment.

I thank you again for investigating this issue and I hope you will alter the code, so the GIT community (me and friends included) can play Farcry in multiplayer over VPN, or other games with similar packet settlement, in the nearby future.

If you want my support for testing this case, just ask.

Best regards,
Elwin

Ark wrote:

ElwinOnline wrote: Time to live: 1

01 00 5e 05 06 07 00 0c 6e 1a d8 59 08 00 45 00
00 26 39 61 00 00 01 11 85 4f 0a 01 01 0a ea 05
06 07 0d ff 16 2e 00 12 16 2a 7f ff ff ff 73 74
61 74 75 73 00 00 00 00 00 00 00 00

There's the problem. GIT expects a TTL of higher then 8 currently.
There is no workaround for this other then a big rewrite of how GIT handles knowing if a packet its sniffing is one it sent out itself in order to prevent an infinite loop of re-sending packets back and forth.

Well there is some existing code for ARP only that keeps track of source MAC addresses in order to prevent duplication, but it would still be some work and time to make sure nothing breaks by using that instead of TTL checks for IPv4 and IPX. At this time I can't be adding features to GIT unless I convert it to a payed program though. If people were willing to pay a small one-time fee to buy GIT, I could better support new features. The only problem is that it is difficult to support a program that interacts with 3rd party programs that we don't usually have available, so people that would buy the program would get the impression they aren't being supported because we can't walk them through setting up their particular game and network configuration.

Keeping track of source MAC addresses instead of TTL checks sounds as a very good solution. But it takes development time of course.

Well, in case you ask a small one-time fee people will expect things like good documentation, config- and installation wizards, FAQ-list, regularly updates of the website, support for game and network configuration as you mentioned, etc. Maybe you even need to write code for a trailtime version with the necessary security checks.
So the amount of time you need to spent will exponentially increase I think.

There’s also another issue you have to deal with. With many popular games it’s simply possible to make use of a workaround for playing LAN games over the internet.
i.e. over a VPN connection and a making a connection to the IP of the hosting gameserver via direct connect feature of the game or by the favourite server list.

Fact is that FarCry doesn’t offer a direct connect feature or such. So in this case GIT could come in. Also in situations a VPN connection isn’t possible or for those people who aren’t be able to do so.

What I trying to say is the situations GIT is worth paying maybe to rare, so it would be difficult to get your spent time and obligations in proportion of the collected fees.
But I could be wrong of course.

Maybe there are some programmers out there who are be able and willing to support GIT in development (open source?). Unfortunately I’m not one of those. It goes beyond my knowledge.

Nevertheless, in my opinion you did a very good job writing this code (and made it public).
Of course it’s up to you the time you’ll spend on it. But the lack of obligations, the drive to improve your program and the positive reactions of the internet community could keep up the fun for doing so.

GIT v0.98 contains the ability to keep track of MAC source addresses instead of modifying the TTL.