Tweet
Hope this is the right place for this post.
@Baker: I got a question on proQuake, hope you can help:
The automatic interface detection of the proQuake 4.00 client seems to be broken in the following two cases:
1) >1 interface with a local IP
2) internet connection via UPnP
Scenario 1 happens when you've got >= 2 NICs and both have local IPs. Every laptop has 2 NICs (wireless + rj45), many have more because of virtual NICs (for VPN access into work/university networks or created by virtualization software like OpenBox).
I'm not sure what proQuake does in that case but it seems to guess which one to chose. For me it always tries to use the OpenBox interface (static IP, 192.168.135.0/24 network) that has no gateway defined and thus can't connect to any server.
Scenario 2 happens when you're behind NAT and your router and OS support UPnP (true for most modern routers and OSs, I tried on WinXp with a LinkSys WRT54GL router). The OS assigns the public IP of the router to a virtual interface and proQuake seems to think the PC was connected directly to the internet and uses that interface instead of the local one. Since it doesn't support UPnp, this fails too.
You can fix the issues described here by using the -oldnet command line parameter. Using it always doesn't seem to hurt. So what's the advantage of the current default behaviour? What does it try to do?
@Baker: I got a question on proQuake, hope you can help:
The automatic interface detection of the proQuake 4.00 client seems to be broken in the following two cases:
1) >1 interface with a local IP
2) internet connection via UPnP
Scenario 1 happens when you've got >= 2 NICs and both have local IPs. Every laptop has 2 NICs (wireless + rj45), many have more because of virtual NICs (for VPN access into work/university networks or created by virtualization software like OpenBox).
I'm not sure what proQuake does in that case but it seems to guess which one to chose. For me it always tries to use the OpenBox interface (static IP, 192.168.135.0/24 network) that has no gateway defined and thus can't connect to any server.
Scenario 2 happens when you're behind NAT and your router and OS support UPnP (true for most modern routers and OSs, I tried on WinXp with a LinkSys WRT54GL router). The OS assigns the public IP of the router to a virtual interface and proQuake seems to think the PC was connected directly to the internet and uses that interface instead of the local one. Since it doesn't support UPnp, this fails too.
You can fix the issues described here by using the -oldnet command line parameter. Using it always doesn't seem to hurt. So what's the advantage of the current default behaviour? What does it try to do?
Comment