Debian Bug report logs - #14445
xquake: Networked game problems

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: jgoerzen@complete.org

To: submit@bugs.debian.org

Subject: xquake: Networked game problems

Date: Mon, 3 Nov 1997 14:45:11 -0600

Package: xquake
Version: 1.06-6

Hi,

I realize that due to the nature of this package, you may not be able to
help out with this issue.  I am hoping that you could at least point me to
someone that can.

When playing a networked game, Quake always latches on to a particular
network device.  In my case, I have ethernet and PPP network devices
present.  While it should be selecting the PPP device, it instead picks the
Ethernet one and gives me no opportunity to change this behavior. 
Therefore, without a lot of trickery (editing /etc/hosts and changing the
hostname), I cannot play a networked game over the Internet.

Most programs will simply open a socket (for instance, at port 26000) and
wait for connections in server mode (or, in client mode, will simply open a
sockect to the desired address and let the OS select the proper interface.)
By not doing this, Quake is bypassing my system's routing configuration and
makes the network play unusable.

-- System Information
Debian Release: 1.3
Kernel Version: Linux garfield 2.0.31 #1 Sat Oct 18 18:39:36 CDT 1997 i586 unknown

Versions of the packages xquake depends on:
libc5	Version: 5.4.33-7
xlib6	Version: 3.3.1-1
quake-lib	Version: 1.06-3
quake-lib-stub	Not installed or no info

Message #10 received at 14445@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: jgoerzen@complete.org, 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: Tue, 4 Nov 1997 01:08:24 -0500

jgoerzen@complete.org wrote:
> I realize that due to the nature of this package, you may not be able to
> help out with this issue.  I am hoping that you could at least point me to
> someone that can.

You're right, I may not be able to help. I can try to pass this on to
the person who is in charge of the linux quake port.

> When playing a networked game, Quake always latches on to a particular
> network device.  In my case, I have ethernet and PPP network devices
> present.  While it should be selecting the PPP device, it instead picks the
> Ethernet one and gives me no opportunity to change this behavior. 
> Therefore, without a lot of trickery (editing /etc/hosts and changing the
> hostname), I cannot play a networked game over the Internet.
> 
> Most programs will simply open a socket (for instance, at port 26000) and
> wait for connections in server mode (or, in client mode, will simply open a
> sockect to the desired address and let the OS select the proper interface.)
> By not doing this, Quake is bypassing my system's routing configuration and
> makes the network play unusable.

Do you have this problem both when you use quake as a server, and as a
client? You mention trickery with /etc/hostname - what do you have to
do to that file to make it work?

When you say that quake seems to be latching on to a particular
network device, what exactly makes you think that is what it's doing?
(I've never heard of a program even being able to specify what device
it uses, it should simply send out packets, and the kernel's routing
tables direct them to the appropriate network device. But I'm not a
network guru, and I suppose this behavior is possible - but I'd like
to see the evidence that makes you think it's doing this.)

Finally, can you reproduce the same problem with squake?

-- 
see shy jo

Message #15 received at 14445@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Joey Hess <joey@kitenet.net>

Cc: 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: 04 Nov 1997 06:12:58 -0600

Joey Hess <joey@kitenet.net> writes:

> > Most programs will simply open a socket (for instance, at port 26000) and
> > wait for connections in server mode (or, in client mode, will simply open a
> > sockect to the desired address and let the OS select the proper interface.)
> > By not doing this, Quake is bypassing my system's routing configuration and
> > makes the network play unusable.
> 
> Do you have this problem both when you use quake as a server, and as a
> client? You mention trickery with /etc/hostname - what do you have to

At least as the server.  It may not be a problem with the client.  The
reason I am not sure is that the person I was working to play with was
using Quake for Linux as well, and having the exact same problem....

> do to that file to make it work?

Basically, what I had to do is edit /etc/hosts and put an entry for my
PPP connection at the very top of that file.  Then I ran the hostname
program to set the hostname to that name.  After doing that, the
server at least worked.

When I did this, and my friend left his system alone, he was able to
connect to the game if I was server but I could still not connect to
the game if he was server, so I suspect the problem is only with the
server, but it may be with the client also...

> When you say that quake seems to be latching on to a particular
> network device, what exactly makes you think that is what it's doing?

Well, in the "address" area when I start a game (it is an unchangable
field above the Port area), it shows the IP address of my Ethernet
connection instead of my PPP connection.  This is the first tip-off.
When I changed /etc/hosts and the hostname so that quake would think
that my primary hostname is that which corresponds to a PPP
connection, it would show the address of the PPP connection in that
box and everything would work fine.  So it seems the only logical answer.

> (I've never heard of a program even being able to specify what device
> it uses, it should simply send out packets, and the kernel's routing

Some programs like Samba let you explicitly specify this behavior.
For instance, I can tell my Samba to only accept packets from my eth0
device and ignore those from my ppp0 device for security reasons.  I
think sendmail has some settings like this as well.  This type of
thing is important in machines with multiple network interfaces
(usually two ethernet cards, acting as a router or bridge or something
of that sort).  My machine happens to have an Ethernet interface (to
my LAN), and a PPP interface (to the Internet).  You are right, it
should not pick one specific connection, but it appears that it is
doing just that.

> tables direct them to the appropriate network device. But I'm not a
> network guru, and I suppose this behavior is possible - but I'd like
> to see the evidence that makes you think it's doing this.)
> 
> Finally, can you reproduce the same problem with squake?

Unfortunately, SVGALib is not compatible with my Mach64-based card so
I cannot try squake on my system.  I believe that the friend that I
was playing with when I found out about this problem was using squake,
though.

-- 
John Goerzen          | Developing for Debian GNU/Linux (www.debian.org)
Custom Programming    | Debian GNU/Linux is a free replacement for
jgoerzen@complete.org | DOS/Windows -- check it out at www.debian.org.
----------------------+----------------------------------------------
Find out how to avoid all those pesky crashes, lockups, application errors,
and slow applications at http://www.debian.org -- Debian can replace Windows
95 with a much more stable operating system.

Message #20 received at 14445@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wakkerma@wi.leidenuniv.nl>

To: Joey Hess <joey@kitenet.net>, 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: Tue, 4 Nov 1997 14:56:45 +0100

[Message part 1 (text/plain, inline)]

Previously Joey Hess wrote:
> (I've never heard of a program even being able to specify what device
> it uses, it should simply send out packets, and the kernel's routing
> tables direct them to the appropriate network device. But I'm not a
> network guru, and I suppose this behavior is possible - but I'd like
> to see the evidence that makes you think it's doing this.)

All virtual-hosting software does this.

Wichert.

-- 
==============================================================================
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: wakkerma@wi.LeidenUniv.nl
WWW: http://www.wi.leidenuniv.nl/~wakkerma/

[Message part 2 (application/pgp-signature, inline)]

Message #25 received at 14445@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Wichert Akkerman <wakkerma@wi.leidenuniv.nl>, 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: Tue, 4 Nov 1997 12:23:38 -0500

Wichert Akkerman wrote:
> Previously Joey Hess wrote:
> > (I've never heard of a program even being able to specify what device
> > it uses, it should simply send out packets, and the kernel's routing
> > tables direct them to the appropriate network device. But I'm not a
> > network guru, and I suppose this behavior is possible - but I'd like
> > to see the evidence that makes you think it's doing this.)
> 
> All virtual-hosting software does this.

Ah, good point, so it does.

-- 
see shy jo

Message #30 received at 14445@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: John Goerzen <jgoerzen@complete.org>

Cc: 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: Tue, 4 Nov 1997 13:46:43 -0500

John Goerzen wrote:
> Basically, what I had to do is edit /etc/hosts and put an entry for my
> PPP connection at the very top of that file.  Then I ran the hostname
> program to set the hostname to that name.  After doing that, the
> server at least worked.

So it it is resolving the hostname to find your ip address.

The best solution for you might be to modify ip-up so it edits
/etc/hosts and changes the ip address in front of your hostname to
whatever ip ppp is using. I suspect that if you don't do this, you
might have problems with other programs, like ytalk.

I don't really think this is a bug, I think the way quake's networking 
is designed, it has to work this way for some reason.

-- 
see shy jo

Message #35 received at 14445@bugs.debian.org (full text, mbox, reply):

From: John Goerzen <jgoerzen@complete.org>

To: Joey Hess <joey@kitenet.net>

Cc: 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: 05 Nov 1997 17:52:08 -0600

Joey Hess <joey@kitenet.net> writes:

> John Goerzen wrote:
> > Basically, what I had to do is edit /etc/hosts and put an entry for my
> > PPP connection at the very top of that file.  Then I ran the hostname
> > program to set the hostname to that name.  After doing that, the
> > server at least worked.
> 
> So it it is resolving the hostname to find your ip address.

Apparently...

> The best solution for you might be to modify ip-up so it edits
> /etc/hosts and changes the ip address in front of your hostname to
> whatever ip ppp is using. I suspect that if you don't do this, you
> might have problems with other programs, like ytalk.

This cannot be done at present for a few reasons.  First, I run my own
nameserver and it is not practical to change the entry in the
nameserver every time the connection goes up or down.  Secondly, doing
that prevents talk from working over my local Ethernet, which is
certainly not a desirable side effect.

> I don't really think this is a bug, I think the way quake's networking 
> is designed, it has to work this way for some reason.

From what I can tell, quake uses ordinary UDP for its networking.  My
suspicion is that it was originally ported from DOS and they just
assumed that nobody could possibly have more than one network-capable
device in the computer at once.  On Linux, it is quite common to be in
this situation.

Quake also is unable to handle players both from the local Ethernet
and from PPP at the same time, no matter what I set it up as.

AFAIK, there should be no reason that it should bind to only one
interface.

Every other program I've seen will work fine on this system.  That
includes sendmail, inn, various other networked games, Samba, NFS, etc...
I see no reason that Quake should be different.

-- 
John Goerzen          | Developing for Debian GNU/Linux (www.debian.org)
Custom Programming    | Debian GNU/Linux is a free replacement for
jgoerzen@complete.org | DOS/Windows -- check it out at www.debian.org.
----------------------+----------------------------------------------
Find out how to avoid all those pesky crashes, lockups, application errors,
and slow applications at http://www.debian.org -- Debian can replace Windows
95 with a much more stable operating system.

Message #40 received at 14445@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: John Goerzen <jgoerzen@complete.org>

Cc: 14445@bugs.debian.org

Subject: Re: Bug#14445: xquake: Networked game problems

Date: Thu, 6 Nov 1997 01:19:47 -0500

John Goerzen wrote:
> This cannot be done at present for a few reasons.  First, I run my own
> nameserver and it is not practical to change the entry in the
> nameserver every time the connection goes up or down.  Secondly, doing
> that prevents talk from working over my local Ethernet, which is
> certainly not a desirable side effect.

What I meants was to edit /etc/hosts from ip-up. Quake is obviously looking
there first to resolve the hostname. I think it's possible to do this and
keep ytalk working - I've seen threads about it. (Gee, I'm glad I've always
had a static ip. ;-)
 
> >From what I can tell, quake uses ordinary UDP for its networking.  My
> suspicion is that it was originally ported from DOS and they just
> assumed that nobody could possibly have more than one network-capable
> device in the computer at once.  On Linux, it is quite common to be in
> this situation.

Here's a bit more info about quake's networking, that I dredged up out of
my memory. Quake uses UDP, and it encloses the IP address of your computer
(of course in this case, it's the IP address it picks from which ever of the
interfaces it prefers) inside the packets it sends out. That's why there has 
to be a seperate kernel module to make quake work over ip masq. It's weird 
and nonstandard, and only a few other programs put the ip address into their 
packets this way.

I'm convinced that the fact that the quake network protocol is designed this
way is the cause of your problems - and I'm sure that the protocol is not 
about to be changed. You're probably right that they didn't even think about
dual interfaces.

> Quake also is unable to handle players both from the local Ethernet
> and from PPP at the same time, no matter what I set it up as.

You might be able to make it work if you use ip masqerading for your local
network, and set up /etc/hosts so your hostname resolves to your ppp ip
address. Just a guess.
 
I really hate it I can't help you more. Not having the source really sucks.
I could try to forward this upstream, but I doubt I'd get farther than the
guy who ports quake to linux -- and he's not even a member of ID software. 
The chances of my getting the ear of one of the designers and getting them 
to rethink their networking for quake 2 is miniscule. Sorry.

-- 
see shy jo

Message #47 received at 14445-close@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: 14445-close@bugs.debian.org

Subject: Bug#14445: fixed in quakeforge 0.1.0-1

Date: 25 Jan 2000 17:23:36 -0000

We believe that the bug you reported is fixed in the latest version of
quakeforge, which has been installed in the Debian FTP archive:
quakeforge_0.1.0-1.tar.gz
  to dists/potato/contrib/source/games/quakeforge_0.1.0-1.tar.gz
  replacing quakeforge_0.0.9-1.tar.gz
quakeforge_0.1.0-1.tar.gz
  to dists/woody/contrib/source/games/quakeforge_0.1.0-1.tar.gz
  replacing quakeforge_0.0.9-1.tar.gz
quake-svga_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-svga_0.1.0-1.deb
  replacing quake-svga_0.0.9-1.deb
quake-svga_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-svga_0.1.0-1.deb
  replacing quake-svga_0.0.9-1.deb
quake-x11_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-x11_0.1.0-1.deb
  replacing quake-x11_0.0.9-1.deb
quake-x11_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-x11_0.1.0-1.deb
  replacing quake-x11_0.0.9-1.deb
quake-sdl_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-sdl_0.1.0-1.deb
  replacing quake-sdl_0.0.9-1.deb
quake-sdl_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-sdl_0.1.0-1.deb
  replacing quake-sdl_0.0.9-1.deb
quake-gl_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-gl_0.1.0-1.deb
  replacing quake-gl_0.0.9-1.deb
quake-gl_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-gl_0.1.0-1.deb
  replacing quake-gl_0.0.9-1.deb
quakeforge_0.1.0-1.dsc
  to dists/potato/contrib/source/games/quakeforge_0.1.0-1.dsc
  replacing quakeforge_0.0.9-1.dsc
quakeforge_0.1.0-1.dsc
  to dists/woody/contrib/source/games/quakeforge_0.1.0-1.dsc
  replacing quakeforge_0.0.9-1.dsc
quake-3dfx_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-3dfx_0.1.0-1.deb
  replacing quake-3dfx_0.0.9-1.deb
quake-3dfx_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-3dfx_0.1.0-1.deb
  replacing quake-3dfx_0.0.9-1.deb
quake-server_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-server_0.1.0-1.deb
  replacing quake-server_0.0.9-1.deb
quake-server_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-server_0.1.0-1.deb
  replacing quake-server_0.0.9-1.deb
quake-ggi_0.1.0-1_i386.deb
  to dists/potato/contrib/binary-i386/games/quake-ggi_0.1.0-1.deb
  replacing quake-ggi_0.0.9-1.deb
quake-ggi_0.1.0-1_i386.deb
  to dists/woody/contrib/binary-i386/games/quake-ggi_0.1.0-1.deb
  replacing quake-ggi_0.0.9-1.deb

Note that this package is not part of the released stable Debian
distribution.  It may have dependencies on other unreleased software,
or other instabilities.  Please take care if you wish to install it.
The update will eventually make its way into the next released Debian
distribution.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 14445@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joseph Carter <knghtbrd@debian.org> (supplier of updated quakeforge package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.6
Date: Sun, 16 Jan 2000 13:26:24 -0800
Source: quakeforge
Binary: quake-svga quake-x11 quake-sdl quake-gl quake-3dfx quake-server quake-ggi
Architecture: source i386
Version: 0.1.0-1
Distribution: frozen unstable
Urgency: high
Maintainer: Joseph Carter <knghtbrd@debian.org>
Description: 
 quake-3dfx - First person shooting game - 3dfx GL version
 quake-ggi  - First person shooting game - GGI version
 quake-gl   - First person shooting game - GL version
 quake-sdl  - First person shooting game - SDL version
 quake-server - First person shooting game - dedicated server
 quake-svga - First person shooting game - SVGALib version
 quake-x11  - First person shooting game - X11 version
Closes: 14445 47954 48018 53533 54152 54153 54221 54451 54488 54530 54595 54634 54742 54747 54749 54868
Changes: 
 quakeforge (0.1.0-1) frozen unstable; urgency=HIGH
 .
   * "0.0.9-1" was actually "0.1-20000103-1"
   * Fixed the sig4's in the SVGALib-using targets
   * replaced qwprogs.dat, no longer segfaults (Closes: #54152)
   * -ip will let you bind a specific IP (Closes: #14445)  (I hope)
   * quake-svga is suid root like other svgalib apps now (Closes: #47954)
   * quake-x11 restores repeat properly on normal exit (Closes: #48018)
   * If /dev/dsp can't be opened, just don't use sound (Closes: #53533)
   * The return of the wrapper scripts..  They've been rewritten a bit for
     dealing with unpacked pak files.  A new quake-lib-stub is needed if your
     pak files are not all lowercase.  (Closes: #54153, #54221, #54634)
   * svgalib targets are i386 only at the moment  =<  (Closes: #54451)
   * Built with newer libsdl  (Closes: #54488)
   * README now notes the gl_ztrick issue..  Essentially ztrick is a hack
     Id used to keep from clearing the Z buffer, it worked with older Mesa
     and with the 3dfx GL MCD.  Mesa 3+ flicker madly, so it defaults to off
     in the -gl target.  You still have to disable it by hand for the -3dfx
     target (since it's intended to be used with the 3dfx GL MCD..)  If set
     once to 0 it will be saved in that state.  (Closes: #54530)
   * If you want to start -svga and -3dfx from X, use open.  Documented this
     in the README.  (Closes: #54595)
   * Package relationships updated/fixed.  (Closes: #54747, #54868)
   * docs are now installed more sanely.  (Closes: #54749)
   * bins and data owned by games isn't going to happen  (Closes: #54742)
Files: 
 164d5e222fb02f3632e13d04acfda075 580 contrib/games optional quakeforge_0.1.0-1.dsc
 e568f2a8c5f0c8c3b4367fb03369543c 1310477 contrib/games optional quakeforge_0.1.0-1.tar.gz
 181f1914adfbcd747223dd6b80813800 469614 contrib/games optional quake-svga_0.1.0-1_i386.deb
 8d2f4596709f97d9e5c01f050e09e344 470930 contrib/games optional quake-x11_0.1.0-1_i386.deb
 f98e7aff35bfcfb3f0160673cf2b1a29 469658 contrib/games optional quake-ggi_0.1.0-1_i386.deb
 4eed8def4e6253febfdb2d10ac4af0d3 461888 contrib/games optional quake-gl_0.1.0-1_i386.deb
 9434aa1d9f59a7b82410eefe8f76a76c 452806 contrib/games optional quake-3dfx_0.1.0-1_i386.deb
 7ff86f5b72f5db06d449980693488208 462778 contrib/games optional quake-sdl_0.1.0-1_i386.deb
 9d8cc200809f4dba4006ce60166767f8 263014 contrib/games optional quake-server_0.1.0-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: The default gpg comment sucks!  ;>

iEYEARECAAYFAjiKzCMACgkQj/fXo9z52rNGPQCgimgLSpn5ejkR/9EfXQbBnX5a
AW0AnAxHsxzrU8KizaTdiNwZTJMJ/rk8
=kni8
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.