Freeciv 2.0.8

[Temlakos]

Everyone:

Would SELinux interfere with Freeciv?

Freeciv works in single-player mode primarily by starting its own server 
process and connecting to it. But when I try to start a Freeciv client, 
I get this message:

>  Starting server...
>  Couldn't connect to the server.
>  We probably couldn't start it from here.
>  You'll have to start one manually. Sorry.... 
Then when I /do/ try to start a Freeciv server manually, and load a 
game, I can't connect. When I try to use Freeciv's client to "connect to 
a network game"--well, I see a few games out on the Internet, but /none/ 
in my "Local Area Network."

When I run Freeciv on a Windows box--no problem at all.

What might be the issue? Actually, I tried disabling SELinux, and then 
running Freeciv right away. No joy. (Whenever I process updates to 
selinux-policy and selinux-policy-targeted, I always disable SELinux, 
process the update, re-enforce SELinux, and restart the system for 
relabeling.)

It's either some obscure element of SELinux, or it's the kernel. I don't 
even know how to go about diagnosing it.

I would appreciate any suggestion. I know it's "just a game," but 
anything that interferes with a game, might also interfere with a 
business or professional application that I might try to develop, that 
needs to do something similar.

Temlakos

[Bruno Wolff III]

On Mon, Aug 13, 2007 at 11:37:58 -0400,
  Temlakos <temlakos(a)gmail.com&gt; wrote:
>  Everyone:
>  
>  Would SELinux interfere with Freeciv?
>  
>  Freeciv works in single-player mode primarily by starting its own server 
>  process and connecting to it. But when I try to start a Freeciv client, 
>  I get this message: 
In theory it could, but it seems unlikely that targeted policy would
interfere when you are starting it from the desktop.

>  >Starting server...
>  >Couldn't connect to the server.
>  >We probably couldn't start it from here.
>  >You'll have to start one manually. Sorry.... 
What do your logs say?
You can see if there were any AVC denials from selinux. Also, freeciv
might have its own logging that could tell you more about what is going
wrong.
Firewall logs most likely end up in /var/log/messages and would be good to
check as well.

>  Then when I /do/ try to start a Freeciv server manually, and load a 
>  game, I can't connect. When I try to use Freeciv's client to "connect to 
>  a network game"--well, I see a few games out on the Internet, but /none/ 
>  in my "Local Area Network." 
This makes me think that firewall rules are a possible culprit.

[Temlakos]

Bruno Wolff III wrote:
>  On Mon, Aug 13, 2007 at 11:37:58 -0400,
>    Temlakos <temlakos(a)gmail.com&gt; wrote:
>    
> > Everyone:
> >
> > Would SELinux interfere with Freeciv?
> >
> > Freeciv works in single-player mode primarily by starting its own server 
> > process and connecting to it. But when I try to start a Freeciv client, 
> > I get this message:
> >     
>
>  In theory it could, but it seems unlikely that targeted policy would
>  interfere when you are starting it from the desktop.
>
>    
> >> Starting server...
> >> Couldn't connect to the server.
> >> We probably couldn't start it from here.
> >> You'll have to start one manually. Sorry....
> >>       
>
>  What do your logs say?
>  You can see if there were any AVC denials from selinux. Also, freeciv
>  might have its own logging that could tell you more about what is going
>  wrong.
>  Firewall logs most likely end up in /var/log/messages and would be good to
>  check as well.
>
>    
> > Then when I /do/ try to start a Freeciv server manually, and load a 
> > game, I can't connect. When I try to use Freeciv's client to "connect to
>
> > a network game"--well, I see a few games out on the Internet, but /none/ 
> > in my "Local Area Network."
> >     
>
>  This makes me think that firewall rules are a possible culprit.
>
>     
All right, here are my firewall rules:

>  # Firewall configuration written by system-config-securitylevel
>  # Manual customization of this file is not recommended.
>  *filter
>  :INPUT ACCEPT [0:0]
>  :FORWARD ACCEPT [0:0]
>  :OUTPUT ACCEPT [0:0]
>  :RH-Firewall-1-INPUT - [0:0]
>  -A INPUT -j RH-Firewall-1-INPUT
>  -A FORWARD -j RH-Firewall-1-INPUT
>  -A RH-Firewall-1-INPUT -i lo -j ACCEPT
>  -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
>  -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
>  -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
>  -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
>  -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
>  -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5555 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 5555 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5432 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 5432 
>  -j ACCEPT
>  -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
>  COMMIT 
The logs say nothing about the programs civclient or civserver, nor do I 
see anything in the logs referable to a mishap at the time I tried to 
start those applications.

What line should I add, to grant to my system the necessary permissions?

Temlakos

[Bruno Wolff III]

On Mon, Aug 13, 2007 at 14:13:39 -0400,
  Temlakos <temlakos(a)gmail.com&gt; wrote:
>  >This makes me think that firewall rules are a possible culprit.
>  >
>  >  
>  All right, here are my firewall rules: 
iptables -L is another way to get the firewall rules that shows what they
really are. What you have is what they are supposed to be. While they
are probably the same (though iptables output format is different)
it is possible for them to be different.

>  ># Firewall configuration written by system-config-securitylevel
>  ># Manual customization of this file is not recommended.
>  >*filter
>  >:INPUT ACCEPT [0:0]
>  >:FORWARD ACCEPT [0:0]
>  >:OUTPUT ACCEPT [0:0]
>  >:RH-Firewall-1-INPUT - [0:0]
>  >-A INPUT -j RH-Firewall-1-INPUT
>  >-A FORWARD -j RH-Firewall-1-INPUT
>  >-A RH-Firewall-1-INPUT -i lo -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
>  >-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5555 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 5555 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5432 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 5432 
>  >-j ACCEPT
>  >-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
>  >COMMIT 
I don't see anything in here that is interface specific except the rule
to accept all traffic on lo. The only IP specific address is in the multicast
range so that shouldn't be a problem. This makes the firewall being the
problem scenario seem a lot less likely.


>  The logs say nothing about the programs civclient or civserver, nor
> do I 
>  see anything in the logs referable to a mishap at the time I tried to 
>  start those applications. 
There wouldn't be program names. There would be information from the
contents of the packets being logged such a IP address on ports.

>  What line should I add, to grant to my system the necessary
> permissions? 
For a quick test of the firewall, you could disable it (preferably while
your local network is disconnected from the internet) and see if it helps.

You help locating freeciv log information, you could look at the documentation
for it, searching with google or asking on whatever support sources exist
for the project.

[Tony Nelson]

At 2:09 PM -0500 8/13/07, Bruno Wolff III wrote:
> On Mon, Aug 13, 2007 at 14:13:39 -0400,
>   Temlakos <temlakos(a)gmail.com&gt; wrote:
> > >This makes me think that firewall rules are a possible culprit.
> > >
> > >
> > All right, here are my firewall rules:
>
> iptables -L is another way to get the firewall rules that shows what they
> really are. What you have is what they are supposed to be. While they
> are probably the same (though iptables output format is different)
> it is possible for them to be different. 
I like `iptables -vL` so I can tell the difference between the localhost
rules and the rest.  It also lists the traffic, which is useful in finding
out what rules are getting triggered when something isn't quite right.
tcpdump is also useful; even if you don't understand all of it you may see
the port you need open.

Please don't word-wrap the `iptables -vL` output in the email -- it makes
it hard to read.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:[e-mail]>
      '                              <http://www.georgeanelson.com/>

[Temlakos]

Tony Nelson wrote:
>  At 2:09 PM -0500 8/13/07, Bruno Wolff III wrote:
>    
> > On Mon, Aug 13, 2007 at 14:13:39 -0400,
> >  Temlakos <temlakos(a)gmail.com&gt; wrote:
> >     
> >>> This makes me think that firewall rules are a possible culprit.
> >>>
> >>>
> >>>         
> >> All right, here are my firewall rules:
> >>       
> > iptables -L is another way to get the firewall rules that shows what they
> > really are. What you have is what they are supposed to be. While they
> > are probably the same (though iptables output format is different)
> > it is possible for them to be different.
> >     
>
>  I like `iptables -vL` so I can tell the difference between the localhost
>  rules and the rest.  It also lists the traffic, which is useful in finding
>  out what rules are getting triggered when something isn't quite right.
>  tcpdump is also useful; even if you don't understand all of it you may see
>  the port you need open.
>
>  Please don't word-wrap the `iptables -vL` output in the email -- it makes
>  it hard to read.
>     
Had to do som trial-and-error--turns out that "iptables" is an sbin
command. My "path" doesn't have it.

Herewith the output of '# sbin/iptables -vL':
>  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>   pkts bytes target     prot opt in     out     source               
>  destination         
>  28171   22M RH-Firewall-1-INPUT  all  --  any    any     
>  anywhere             anywhere            
>
>  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>   pkts bytes target     prot opt in     out     source               
>  destination         
>      0     0 RH-Firewall-1-INPUT  all  --  any    any     
>  anywhere             anywhere            
>
>  Chain OUTPUT (policy ACCEPT 26383 packets, 8286K bytes)
>   pkts bytes target     prot opt in     out     source               
>  destination         
>
>  Chain RH-Firewall-1-INPUT (2 references)
>   pkts bytes target     prot opt in     out     source               
>  destination         
>   1412 4273K ACCEPT     all  --  lo     any     anywhere             
>  anywhere            
>     17  1020 ACCEPT     icmp --  any    any     anywhere             
>  anywhere            icmp any
>      0     0 ACCEPT     esp  --  any    any     anywhere             
>  anywhere            
>      0     0 ACCEPT     ah   --  any    any     anywhere             
>  anywhere            
>     18  3185 ACCEPT     udp  --  any    any     anywhere             
>  224.0.0.251         udp dpt:mdns
>      0     0 ACCEPT     udp  --  any    any     anywhere             
>  anywhere            udp dpt:ipp
>      0     0 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            tcp dpt:ipp
>  26379   18M ACCEPT     all  --  any    any     anywhere             
>  anywhere            state RELATED,ESTABLISHED
>      0     0 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            state NEW tcp dpt:ssh
>     95  8202 ACCEPT     udp  --  any    any     anywhere             
>  anywhere            state NEW udp dpt:netbios-ns
>    164 39405 ACCEPT     udp  --  any    any     anywhere             
>  anywhere            state NEW udp dpt:netbios-dgm
>     34  1632 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            state NEW tcp dpt:netbios-ssn
>      1    48 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            state NEW tcp dpt:microsoft-ds
>      0     0 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            state NEW tcp dpt:personal-agent
>      0     0 ACCEPT     udp  --  any    any     anywhere             
>  anywhere            state NEW udp dpt:personal-agent
>      0     0 ACCEPT     tcp  --  any    any     anywhere             
>  anywhere            state NEW tcp dpt:postgres
>      0     0 ACCEPT     udp  --  any    any     anywhere             
>  anywhere            state NEW udp dpt:postgres
>     51  4360 REJECT     all  --  any    any     anywhere             
>  anywhere            reject-with icmp-host-prohibited 
Temlakos

[Temlakos]

Tony Nelson wrote:
>  At 2:09 PM -0500 8/13/07, Bruno Wolff III wrote:
>    
> > On Mon, Aug 13, 2007 at 14:13:39 -0400,
> >  Temlakos <temlakos(a)gmail.com&gt; wrote:
> >     
> >>> This makes me think that firewall rules are a possible culprit.
> >>>
> >>>
> >>>         
> >> All right, here are my firewall rules:
> >>       
> > iptables -L is another way to get the firewall rules that shows what they
> > really are. What you have is what they are supposed to be. While they
> > are probably the same (though iptables output format is different)
> > it is possible for them to be different.
> >     
>
>  I like `iptables -vL` so I can tell the difference between the localhost
>  rules and the rest.  It also lists the traffic, which is useful in finding
>  out what rules are getting triggered when something isn't quite right.
>  tcpdump is also useful; even if you don't understand all of it you may see
>  the port you need open.
>
>  Please don't word-wrap the `iptables -vL` output in the email -- it makes
>  it hard to read.
>     
All right, I'll try that again:

Below is the output of '# sbin/iptables -vL' on my system:

]# /sbin/iptables -vL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               
destination        
28171   22M RH-Firewall-1-INPUT  all  --  any    any     
anywhere             anywhere           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               
destination        
    0     0 RH-Firewall-1-INPUT  all  --  any    any     
anywhere             anywhere           

Chain OUTPUT (policy ACCEPT 26383 packets, 8286K bytes)
 pkts bytes target     prot opt in     out     source               
destination        

Chain RH-Firewall-1-INPUT (2 references)
 pkts bytes target     prot opt in     out     source               
destination        
 1412 4273K ACCEPT     all  --  lo     any     anywhere             
anywhere           
   17  1020 ACCEPT     icmp --  any    any     anywhere             
anywhere            icmp any
    0     0 ACCEPT     esp  --  any    any     anywhere             
anywhere           
    0     0 ACCEPT     ah   --  any    any     anywhere             
anywhere           
   18  3185 ACCEPT     udp  --  any    any     anywhere             
224.0.0.251         udp dpt:mdns
    0     0 ACCEPT     udp  --  any    any     anywhere             
anywhere            udp dpt:ipp
    0     0 ACCEPT     tcp  --  any    any     anywhere             
anywhere            tcp dpt:ipp
26379   18M ACCEPT     all  --  any    any     anywhere             
anywhere            state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  any    any     anywhere             
anywhere            state NEW tcp dpt:ssh
   95  8202 ACCEPT     udp  --  any    any     anywhere             
anywhere            state NEW udp dpt:netbios-ns
  164 39405 ACCEPT     udp  --  any    any     anywhere             
anywhere            state NEW udp dpt:netbios-dgm
   34  1632 ACCEPT     tcp  --  any    any     anywhere             
anywhere            state NEW tcp dpt:netbios-ssn
    1    48 ACCEPT     tcp  --  any    any     anywhere             
anywhere            state NEW tcp dpt:microsoft-ds
    0     0 ACCEPT     tcp  --  any    any     anywhere             
anywhere            state NEW tcp dpt:personal-agent
    0     0 ACCEPT     udp  --  any    any     anywhere             
anywhere            state NEW udp dpt:personal-agent
    0     0 ACCEPT     tcp  --  any    any     anywhere             
anywhere            state NEW tcp dpt:postgres
    0     0 ACCEPT     udp  --  any    any     anywhere             
anywhere            state NEW udp dpt:postgres
   51  4360 REJECT     all  --  any    any     anywhere             
anywhere            reject-with icmp-host-prohibited