UDP packet loss?

Gamer's Internet Tunnel, formerly Gamer's IPX Tunnel

UDP packet loss?

Postby CyberVenom » Tue Jan 20, 2004 11:38 pm

I am trying to use GIT to tunnel Command and Conquer:
Generals. After running Ethereal packet captures, I
discovered that this game uses UDP port 8086 to
communicate when in LAN-wide chat and game browse
mode. Once it enters a specific game launch chat, it
switched to port 8088. (or maybe higher if there are
multiple games on the LAN?)

So far so good. My friend and I can browse games,
join, and chat in the launch chat. It stops working
when we try to launch the game. It is still using UDP
port 8088 at this point, but the rate of packet
communication goes up. According to my Ethereal
captures run at both ends to diagnose the problem, the
majority of the packets seem to be getting lost by GIT
when more than about 4 UDP packets per second are
transmitted from both ends. These aren't
particularily big packets, either. I have GIT logging
unsent packets and these missing packets do not show
up. :?

I have WinPcap correctly installed on both ends (I
used it in making the Ethereal captures), and I have
GIT set up to look inside all Ethernet frame types
except SNAP. I have the correct UDP ports forwarded.
I have NAT disabled, and only broadcast disabled. It
works fine at lower packet rates.

Another problem seems to be (my brother and another
freind both encounter this) that when the GIT user's
computer has 2 network cards, (built-in ethernet and
add-on wireless in both cases) GIT does not seem to
capture packets at all. Even when the correct
interface is set under Advaced configuration.
:(

-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California

Postby Ark » Wed Jan 21, 2004 12:03 am

GIT dropping packets or not picking any packets up to begin with would be a WinPCap issue. Sometimes Windows puts a dummy device in as the first network device and you have to select the device you want to use in the advanced config window of GIT. Since the game uses UDP and UDP is internet routable, the best way to set it up would be to only forward broadcast and thus only use GIT to establish the game connection. This was tested to work with Warcraft 3 as an example.
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby CyberVenom » Wed Jan 21, 2004 3:06 pm

GIT dropping packets in this case is not a WinPcap issue as I used the same WinPcap driver (simultaneously, I might add) with Ethereal to do my captures for analysis. (I also encountered the same problem when not running Ethereal, so it is not an issue of Ethereal interfering.)

As mentioned in my post, on those two machines that had trouble picking up any packets through GIT, the Advanced Settings had the correct network adapter selected. (ran tests with wrong adapter selected as well just for thoroughness, same result) Are there any confirmed working setups on multiple-interface machines? (I have seen this problem on W2k and W98SE so far)

UDP is indeed internet routable, unfortunately the particular game I am using does not take kindly to any sort of NAT (I think it sends IP addresses in the packet payloads), and it makes substantial use of broadcast packets. Perhaps if everyone involved were non-NATed, we might be able to get by with just broadcast tunneling, but that is not the case. What I need is a full UDP bridge.

I am currently working on a bit of programming of my own to get proper bridging in place. I'll let you know what comes of it.

-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California

Postby Ark » Wed Jan 21, 2004 3:40 pm

GIT captures packets in the recommended way, which is the same way any Winpcap program would use the library. There is nothing particular to GIT that would cause it to ever miss packets as long as Winpcap is providing them. You may be dropping the UDP packets on your internet connection if the LAN game tries to send at a rate faster then your internet connection can handle Games that use UDP or IPX are designed to handle dropped packets and in this case you would actually hinder the game by tunneling UDP inside of TCP because of the retransmission. Try to tunnel UDP inside of UDP since it wont matter if the actual packet or the wrapped packet gets dropped then. As long as the game can handle playing at only the rate of your slowest internet link.
My test machine is Windows 2000 and it has multiple NICs in it, one nForce2 build-in and on Realtek, each on a diffrent subnet. GIT works with no problems on this machine. Full UDP bridging is easy, as long as the only-if-broadcast option is disabled, all UDP packets are forwarded. You only need to check inside of Ethernet II frames if you only care about TCP packets.
One thing GIT does not currently do is forward ARP packets. I have yet to see a game that this provides a problem for, but it is a possibility.
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby CyberVenom » Wed Jan 21, 2004 4:09 pm

Arp should not be an issue unless the game is able to talk directly at the ethernet level, which would require a driver like WinPcap (if a game ever asks to install WinPcap, this would be a dead giveaway.) 8)

I have been using TCP for the tunnelling so far because it is easier for connection-tracking firewalls to handle, but I can run a test using UDP to tunnel.

I don't think my (or my freinds') internet connection is too slow. We all use 768/128 DSL.

I can try anylizing the full GIT logs, and an Ethereal packet dump from each side. If as you say, GIT is using the same mechanism for capturing packets as Ethereal, then the packets in question in Ethereal should coincide with the packets in the GIT forwarded log. The GIT forwarded log should also coincide with the GIT received log on the other end, and the Ethereal dump on the other end. That should tell us if the packets are being lost before GIT picks them up, during the journey over the Net, or before they get output on the other end.

-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California

Postby Ark » Wed Jan 21, 2004 4:19 pm

I'm not completely sure about Ethereal, but I know GIT uses the exact same code practically as Windump (tcpdump port that is available on the same website as winpcap)
There is no reason for GIT to fall behind unless Winpcap drops the packets before GIT gets them if GIT is blocked with a full send queue on a TCP port. Again that would be Winpcap dropping the packets, not GIT, but the difference between GIT and a sniffer there is GIT is trying to do something with the packets that may slow it down.
With 768/128 DSL on both sides, you have a max of 128Kbps in each direction, since you can not send any faster then that. 128K is ISDN speeds, and not all that fast, but should be fast enough for a game to play smoothly, assuming no other bandwidth hogging programs like a P2P app are running.
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby CyberVenom » Wed Jan 21, 2004 4:36 pm

True, 128k isn't terribly fast by webserver standards, but it should be plenty fast for almost any game. Certainly far better than the 33.6k upstream of a 56k dialup. :wink:

Guesstimating by what I remember seeing in the packet dump, I think at peak the game was sending circa 24kbit/s. Obviously UDP as a transport medium should be fast enough to handle this. I would have thought TCP would as well, unless there is significant synchronization chatter over the connection. There was no other major traffic on either machine. (an idle AIM window was the only other internet app running)

As I said, I will try test tonight with full logging on both ends, and tunnelling over UDP. I will post the results here tomorrow. (and maybe some log excerpts). I should be able to give accurate measurements of bandwidth usage and the precise point at which the packets are lost.

-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California

Postby CyberVenom » Thu Jan 22, 2004 5:25 pm

Ok, last night I tested the UDP transport setup described above, as well as logging forwarded, incoming, unforwarded, and a full ethernet dump at both ends.
First, I looked over the unforwarded logs to make sure that nothing important was being rejected. I found no record of anything UDP in the range in question being discarded.

Next I examined the local ethernet dump, the local forwarded log, the remote incoming log and the remote ethernet dump.
I also examined the same path in reverse: remote dump, remote forwarded, local incoming, local dump.

I see the lost packets are captured by GIT, transmitted, and arrive at the encapsulated at the remote interface for GIT to read. After that, GIT does not log them to the incoming.log nor does it unencapulate them and place them on the local network.

This occurs as soon as the packet rate increases beyond about 2 UDP packets per second. Each of the packets in question is between 54 and 56 bytes long. Encapulated these end up being 96-98 bytes each. During the problematic period, about 10 packets per second are transmitted, of which only 3 are actually de-encapsulated and placed on the network by GIT. This should be reproduceable using a simple UDP packet generator producing 10 packets per second on one network and a pacet capture on another, with GIT bridging between. If you like I can put together such an apllication and give it to you for testing.

If you would like to look at the dump (it is in tcpdump format, so you should be able to use whatever your favorite analysis tool might be), I have posted an excerpt here:
http://sablesoftware.com/udploss.dump
In this excerpt, 10.0.0.6 is the local machine, while 192.168.0.2 is the remote machine. (externals are 66.116.70.105 and 66.116.69.76 respectively)

-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California

Postby Vortexx » Mon Mar 01, 2004 12:47 pm

Maybe winpcab could be tweaked set a maximum packet speed or something, not elegant but it might provide a workaround?
Vortexx
 
Posts: 3
Joined: Sun Feb 29, 2004 3:55 am
Location: Holland

Postby CyberVenom » Thu Mar 04, 2004 11:23 pm

Somehow I don't think it's WinPcap that is directly responsible, because Ethereal uses it and Ethereal doesn't miss any of the packets.
Anyway, I am trying (in what spare time I have) to write my own ethernet-level bridge using WinPcap, but this project has been slowed by a dead hard drive and lack of time recently... I'll let you guys know if I get anything working.
-CyberVenom
CyberVenom
 
Posts: 25
Joined: Tue Jan 20, 2004 11:03 pm
Location: Ontario, California


Return to GIT

Who is online

Users browsing this forum: Google [Bot] and 34 guests

cron