Ubuntu 13.04 Multiple IP & Issues

[Maxximou5]

To whom may help me:

After an update to Ubuntu 13.04 from 12.04 the server has been having some irregular issues.

• 1. eth0:0-2 doesn't display the IP addresses list on connection anymore.
  2. CS:GO running the command line "-game csgo -console -usercon -ip 74.XXX.XXX.129 +net_public_adr 74.XXX.XXX.129 -port 27017" doesn't actually bind the public address to 74.XXX.XXX.129 but to 74.XXX.XXX.113 (eth0:0). This has caused issues with joining from friends list but doesn't limit the actual connection to the server.
  3. Ubuntu 13.04 continuously asks to perform a "do-release-upgrade" even though the server is already upgraded.

My connection prompt screen shows:

Code: Select all

Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-19-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Future Date Apr 99 66.666.66 PDT 2013

  System load: 0.0                 Memory usage: 42%   Processes:       124
  Usage of /:  12.4% of 295.02GB   Swap usage:   0%    Users logged in: 0

  Graph this data and manage this system at https://landscape.canonical.com/

New release '13.04' available.
Run 'do-release-upgrade' to upgrade to it.

I am not ignorant and yes I know how to use google search, please do not troll me with your ignorance of not reading my words here. If I couldn't find it with google I wouldn't take the time to make an account and ask for help. I have used the workaround to suppress this message; however, I'm looking for a fix, workarounds are for people who work for Valve. If you want a workaround go here: http://ubuntuforums.org/showthread.php?t=2138991

My /etc/network/interfaces is as follows:

Code: Select all

auto lo

iface lo inet loopback

auto eth0:0
iface eth0:0 inet static
        address 74.XXX.XXX.113
        netmask 255.255.255.0
        gateway 74.XXX.XXX.254
        dns-nameservers 8.8.8.8 8.8.4.4

auto eth0:1
iface eth0:1 inet static
        address 74.XXX.XXX.129
        netmask 255.255.255.0
        gateway 74.XXX.XXX.254
        dns-nameservers 8.8.8.8 8.8.4.4

auto eth0:2
iface eth0:2 inet static
        address 74.XXX.XXX.169
        netmask 255.255.255.0
        gateway 74.XXX.XXX.254
        dns-nameservers 8.8.8.8 8.8.4.4

My server shows status as this on all 6 servers:

Code: Select all

hostname:     .Surf // Fragworks.net // 85Tick Stats Vancouver
version : 1.23.0.0/12300 5276 secure  
udp/ip  : 74.XXX.XXX.129:27017  (public ip: 74.XXX.XXX.113)
os      :  Linux
type    :  community dedicated
map     : surf_waterworks
players : 0 humans, 0 bots (12/0 max) (hibernating)

# userid name uniqueid connected ping loss state rate adr
#end
ip
"ip" = "74.XXX.XXX.129"
net_public_adr
"net_public_adr" = "74.XXX.XXX.129" 

eth0:0 - SSH & FTP
eth0:1 - Servers
eth0:2 - MySQL & Apache

Please let me know if more information is necessary, don't be afraid to ask, I've had my coffee.
Thank you.

[Edge100x]

eth0:0-2 doesn't display the IP addresses list on connection anymore.

ifconfig is a deprecated tool, though it is still useful in some circumstances. In general, I recommend using "ip" instead. You can see all IPs bound to your adapter through "ip address".

If you'd like, post the output from "ifconfig -a" and "ip address" here, and we can see if the IPs are being bound correctly.

CS:GO running the command line "-game csgo -console -usercon -ip 74.XXX.XXX.129 +net_public_adr 74.XXX.XXX.129 -port 27017" doesn't actually bind the public address to 74.XXX.XXX.129 but to 74.XXX.XXX.113 (eth0:0). This has caused issues with joining from friends list but doesn't limit the actual connection to the server.

Try removing "+net_public_adr 74.xxx.xxx.129", as that isn't needed and may be causing problems.

Another bug that many Valve games have is that the TCP connection initiator to Steam is broken and does not bind to the correct IP, leading the master browser to use the wrong one. Try adding this firewall rule:

Code: Select all

iptables -A OUTPUT -p tcp -m tcp --dport 27017:27019 --tcp-flags FIN,SYN,RST,ACK SYN -j DROP

3. Ubuntu 13.04 continuously asks to perform a "do-release-upgrade" even though the server is already upgraded.

This one sounds like a glitch in their upgrader script just not removing the generated motd line. As long as you're sure that the upgrade process was successful, deleting the message will probably be a permanent fix for you.

[Maxximou5]

eth0:0-2 doesn't display the IP addresses list on connection anymore.

I still would like to know a way to re-implement the announcement of the eth0(s) on SSH or VNC connect. If this is being answered I am sorry for not understanding.

ifconfig is a deprecated tool, though it is still useful in some circumstances. In general, I recommend using "ip" instead. You can see all IPs bound to your adapter through "ip address".

If you'd like, post the output from "ifconfig -a" and "ip address" here, and we can see if the IPs are being bound correctly.

I have listed both:

Code: Select all

ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3e:45:2f:da brd ff:ff:ff:ff:ff:ff
    inet 74.XXX.XXX.113/24 brd 74.XXX.XXX.255 scope global eth0:0
    inet 74.XXX.XXX.129/24 brd 74.XXX.XXX.255 scope global secondary eth0:1
    inet 74.XXX.XXX.169/24 brd 74.XXX.XXX.255 scope global secondary eth0:2
    inet6 fe80::lawl:bagels:for:days/64 scope link
       valid_lft forever preferred_lft forever

Code: Select all

ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3e:45:2f:da
          inet6 addr: fe80::216:3eff:fe45:2fda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:40971523 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44983899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6127252995 (6.1 GB)  TX bytes:11199916317 (11.1 GB)
          Interrupt:87

eth0:0    Link encap:Ethernet  HWaddr 00:16:3e:45:2f:da
          inet addr:74.XXX.XXX.113  Bcast:74.XXX.XXX.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:87

eth0:1    Link encap:Ethernet  HWaddr 00:16:3e:45:2f:da
          inet addr:74.XXX.XXX.129  Bcast:74.XXX.XXX.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:87

eth0:2    Link encap:Ethernet  HWaddr 00:16:3e:45:2f:da
          inet addr:74.XXX.XXX.169  Bcast:74.XXX.XXX.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:87

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:675689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:675689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:111061027 (111.0 MB)  TX bytes:111061027 (111.0 MB)

Try removing "+net_public_adr 74.xxx.xxx.129", as that isn't needed and may be causing problems.

Another bug that many Valve games have is that the TCP connection initiator to Steam is broken and does not bind to the correct IP, leading the master browser to use the wrong one. Try adding this firewall rule:

Code: Select all

iptables -A OUTPUT -p tcp -m tcp --dport 27017:27019 --tcp-flags FIN,SYN,RST,ACK SYN -j DROP

This unfortunately did not fix my issue.
Steps taken were:

• 1. Disabled UFW and resulted back to using iptables.
  2. Shutdown server and removed +net_public_adr from start-up command line.
  3. Added the command:

  Code: Select all

  iptables -A OUTPUT -p tcp -m tcp --dport 27017:27019 --tcp-flags FIN,SYN,RST,ACK SYN -j DROP

  4. Restarted servers associated with ports 27017-27019
  5. Public address still remains to bind to the first IP and not the one given.
  6. The iptable given lags HLstatsX:CE and blocks some commands from being sent to the server.

  Code: Select all

Here is both of my iptables list (--list & --list-rules):

Code: Select all

 iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere             multiport dports ssh
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:mysql
ACCEPT     udp  --  anywhere             anywhere             udp dpt:1200
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:27020
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:27039
ACCEPT     udp  --  anywhere             anywhere             udp dpt:27020
           udp  --  anywhere             v-74-XXX-XXX-129.unman-vds.internap-seattle.nfoservers.com  udp dpts:27015:27024
ACCEPT     tcp  --  anywhere             v-74-XXX-XXX-129.unman-vds.internap-seattle.nfoservers.com  tcp dpts:27015:27024
ACCEPT     tcp  --  anywhere             v-74-XXX-XXX-113.unman-vds.internap-seattle.nfoservers.com  tcp dpt:ssh
ACCEPT     tcp  --  anywhere             v-74-XXX-XXX-113.unman-vds.internap-seattle.nfoservers.com  tcp dpt:ftp
ufw-before-logging-input  all  --  anywhere             anywhere
ufw-before-input  all  --  anywhere             anywhere
ufw-after-input  all  --  anywhere             anywhere
ufw-after-logging-input  all  --  anywhere             anywhere
ufw-reject-input  all  --  anywhere             anywhere
ufw-track-input  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ufw-before-logging-forward  all  --  anywhere             anywhere
ufw-before-forward  all  --  anywhere             anywhere
ufw-after-forward  all  --  anywhere             anywhere
ufw-after-logging-forward  all  --  anywhere             anywhere
ufw-reject-forward  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ufw-before-logging-output  all  --  anywhere             anywhere
ufw-before-output  all  --  anywhere             anywhere
ufw-after-output  all  --  anywhere             anywhere
ufw-after-logging-output  all  --  anywhere             anywhere
ufw-reject-output  all  --  anywhere             anywhere
ufw-track-output  all  --  anywhere             anywhere

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  --  61.164.147.2         anywhere
RETURN     all  --  anywhere             anywhere

Chain fail2ban-ssh-ddos (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain ufw-after-forward (1 references)
target     prot opt source               destination

Chain ufw-after-input (1 references)
target     prot opt source               destination

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination

Chain ufw-after-logging-input (1 references)
target     prot opt source               destination

Chain ufw-after-logging-output (1 references)
target     prot opt source               destination

Chain ufw-after-output (1 references)
target     prot opt source               destination

Chain ufw-before-forward (1 references)
target     prot opt source               destination

Chain ufw-before-input (1 references)
target     prot opt source               destination

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination

Chain ufw-before-logging-input (1 references)
target     prot opt source               destination

Chain ufw-before-logging-output (1 references)
target     prot opt source               destination

Chain ufw-before-output (1 references)
target     prot opt source               destination

Chain ufw-reject-forward (1 references)
target     prot opt source               destination

Chain ufw-reject-input (1 references)
target     prot opt source               destination

Chain ufw-reject-output (1 references)
target     prot opt source               destination

Chain ufw-track-input (1 references)
target     prot opt source               destination

Chain ufw-track-output (1 references)
target     prot opt source               destination

Code: Select all

iptables --list-rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-N fail2ban-ssh-ddos
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-track-input
-N ufw-track-output
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p udp -m udp --dport 1200 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27020 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27039 -j ACCEPT
-A INPUT -p udp -m udp --dport 27020 -j ACCEPT
-A INPUT -d 74.XXX.XXX.129/32 -p udp -m udp --dport 27015:27024
-A INPUT -d 74.XXX.XXX.129/32 -p tcp -m tcp --dport 27015:27024 -j ACCEPT
-A INPUT -d 74.XXX.XXX.113/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -d 74.XXX.XXX.113/32 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A fail2ban-ssh -s 188.190.98.6/32 -j DROP
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh-ddos -j RETURN

3. Ubuntu 13.04 continuously asks to perform a "do-release-upgrade" even though the server is already upgraded.

This one sounds like a glitch in their upgrader script just not removing the generated motd line. As long as you're sure that the upgrade process was successful, deleting the message will probably be a permanent fix for you.

If you want a workaround go here: do-release-upgrade

I will have to wait for that thread to update and will report it back here if there is a fix. As there is still only a workaround and not a fix for the script. Though having the annoyance suppressed is enough.

[Edge100x]

I still would like to know a way to re-implement the announcement of the eth0(s) on SSH or VNC connect.

I'm not sure what you mean. Are you saying that a script was previously running ifconfig and showing results in the MOTD?

Your ip/ifconfig output indicates that you don't have an IP bound to the network adapter itself. That's a nonstandard configuration and I haven't tested it -- it's possible that the game is getting confused by this. Have you tried reconfiguring to have one of your IPs go to "eth0" and the others bound to aliases?

Here is both of my iptables list (--list & --list-rules):

These rules shouldn't do much right now, but have you also tested with everything flushed out (iptables --flush)?

Did you apply the iptables rule I gave you exactly as entered? It only affects outbound SYN requests from your game server to specific remote ports, meaning only TCP connections that the server is initiating. Since the game only opens TCP connections to talk to Steam, and rcon/HLStatsX traffic on the inbound would not match, it should not adversely affect anything. We use this rule on all our customer services here and have never seen problems with it.