Rusty as hell

grodech · 11-24-2010, 11:23 AM

I've been out of the linux admin game for at least 5 years and I could use some help. I've been asked to check on why the control software on a new windows machine can't talk to a device that is running SUSE Linux Enterprise Server 9. At first it's just that there wasn't a route to the subnet that the windows machine was on. I managed to fix that, but now the SUSE server is refusing connections on the ports that the windows server is trying to talk over. As near as I can tell, it's just that nothing is listening on the ports that the software is trying to connect to. I don't think the SUSE server is running any firewall software, but how do I confirm?

fordeck · 11-24-2010, 11:38 AM

You might try:

iptables -L

which would list any rules that are current.

Regards,

Fordeck

grodech · 11-24-2010, 11:58 AM

Would that show me the rules even if the firewall was not running? Or would it error out?

GrapefruiTgirl · 11-24-2010, 12:02 PM

If no iptables firewall is running (enabled) you would see something like this:

Code:

root@reactor: iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@reactor

That's my default, with no firewall. Yours may differ slightly, but the idea is, there's no rules in there, and the default policies are all "ACCEPT".

If you had an iptables firewall running (enabled), you'd see much more stuff.

repo · 11-24-2010, 12:06 PM

Make sure the service you want to contact a the linux machine is running.

Code:

ps ax | grep service-you-want-to-run

Then try to connect to the port/service from the linux machine using telnet or the app you use.

Kind regards

grodech · 11-24-2010, 12:37 PM

ps ax doesn't show iptables running

iptables -L gives me:

Code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http-alt

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I had tried the telnet to the port before posting, and it didn't work. Now I find out that they gave me the wrong port number *d'oh*. A telnet to the correct port number works, but the software still doesn't. Sounds like a software issue to me...

Thanks for all your help.

repo · 11-24-2010, 12:50 PM

You can try to change the port in the program on the windows machine, or change the port the service is listening on the linux machine.

Kind regards

josh.engelbrecht · 11-24-2010, 02:43 PM

That firewall is pretty restrictive, only allowing communications on ports 80,443,591. If you can safely stop the firewall, do so. This would be a quick and easy way to tell if its causing your issues. Or add the port manually to iptables (iptables -A INPUT -p tcp --dport <portNum> -j ACCEPT) to see if that also solvs the problem. May also have to add the udp protocol.

Also try netstat -l (lowercase L) and see if your port you need is listed.