At 02:06 AM 7/14/2008, Brian K. White wrote:

----- Original Message ----- From: "William Hammond" To: "open SuSE mail list" Sent: Monday, July 14, 2008 4:24 AM Subject: [opensuse] Two NIC's, one connected, Ping Both...?

...

The real problem here is that I so far have been unable to connect to a remote 10.3 Server.

Firewall is active, but all necessary ports are open, Server is behind a Router, and the Router is doing Port Forwarding. the this case, 5901,5801,22 ---

This is the only site I can;t get into with Putty. (SSH on 22)

One thing that bothers me is the Server.

Like most modern boards it has two built in NIC.s and 100MB and a 1GB. Both are configured with Private IP's xxx.xxx.xxx.200 and xxx.xxx.xxx.201 (I bet nobody can guess what the xx's represent.. ;-) )

Only one of these RJ45 Ports is connected, but I can Ping them both.

Is that normal...? and is it okay..? or could it be part of my problem..?

It's perfectly normal. If you configured any nic with an ip, whether it's connected or not, and couldn't ping it from localhost, that would be an indication the nic was bad. Not counting completely broken firewall rules.

I should have been more clear, I can ping both from local XP workstations (everything is behind the router), not just inside the box. It just seemed to me that I should only be able to ping the active NIC. So when setting up Port Forwarding I couldn't be sure which was active. The commands you gave me later in this message will solve that.

Start by turning off the firewall, double-checking that you are running ssh, and connecting from a localhost. ie: rcSuSEfirewall2 stop chkconfig sshd on rcsshd start ssh localhost.

Thanks, these are some of the commands I needed

If that works then leave the firewall off and connect (ssh) from a local pc on the lan.

If that works then enable the firewall and try again

If that works then try connecting(ssh) from remote.

What to look for depends on which of the above works and doesn't work.

For example: If you turn the firewall off and still can't ssh localhost, then you are most likely not running sshd. Either way, check netstat -an for attempted tcp connections, and check syslog for possible messages from sshd or possibly the kernel ip filter.

After that comes various routing/netmask/firewall things but I can't very well write the entire process of debugging a service access problem in an email.

Don't rely on ping unless you _know_ that all routers and switches between you & the target are passing icmp. It's more and more common for routers to block icmp (ping, traceroute, etc) these days. You can't ping through one of those.

Are the basic network settings correct? ip, netmask, default-route, nameserver(s)? ifconfig -a netstat -rn cat /etc/resolv.conf

Again, thanks for taking time to give me a diagnostics plan... These are the steps I'm not familiar with in Linux...

-- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

----- Original Message ----- From: "William Hammond" To: "Brian K. White" ; Sent: Wednesday, July 16, 2008 2:42 AM Subject: Re: [opensuse] Two NIC's, one connected, Ping Both...?

At 02:06 AM 7/14/2008, Brian K. White wrote:

...

----- Original Message ----- From: "William Hammond" To: "open SuSE mail list" Sent: Monday, July 14, 2008 4:24 AM Subject: [opensuse] Two NIC's, one connected, Ping Both...?

...

The real problem here is that I so far have been unable to connect to a remote 10.3 Server.

Firewall is active, but all necessary ports are open, Server is behind a Router, and the Router is doing Port Forwarding. the this case, 5901,5801,22 ---

This is the only site I can;t get into with Putty. (SSH on 22)

One thing that bothers me is the Server.

Like most modern boards it has two built in NIC.s and 100MB and a 1GB. Both are configured with Private IP's xxx.xxx.xxx.200 and xxx.xxx.xxx.201 (I bet nobody can guess what the xx's represent.. ;-) )

Only one of these RJ45 Ports is connected, but I can Ping them both.

Is that normal...? and is it okay..? or could it be part of my problem..?

It's perfectly normal. If you configured any nic with an ip, whether it's connected or not, and couldn't ping it from localhost, that would be an indication the nic was bad. Not counting completely broken firewall rules.

Start by turning off the firewall, double-checking that you are running ssh, and connecting from a localhost. ie: rcSuSEfirewall2 stop chkconfig sshd on rcsshd start ssh localhost.

If that works then leave the firewall off and connect (ssh) from a local pc on the lan.

If that works then enable the firewall and try again

If that works then try connecting(ssh) from remote.

What to look for depends on which of the above works and doesn't work.

For example: If you turn the firewall off and still can't ssh localhost, then you are most likely not running sshd. Either way, check netstat -an for attempted tcp connections, and check syslog for possible messages from sshd or possibly the kernel ip filter.

After that comes various routing/netmask/firewall things but I can't very well write the entire process of debugging a service access problem in an email.

Don't rely on ping unless you _know_ that all routers and switches between you & the target are passing icmp. It's more and more common for routers to block icmp (ping, traceroute, etc) these days. You can't ping through one of those.

Are the basic network settings correct? ip, netmask, default-route, nameserver(s)? ifconfig -a netstat -rn cat /etc/resolv.conf

First, let me thank you again, rarely do I see such a complete description of the debugging process. Very helpful.

I can SSH from a local workstation into the Server. The plus is that I can access the workstation remotely and then SSH to the server.

I followed you script, but my knowledge is thin, so I don't know how to interpret the results.

ifconfig -a eth0 Link encap:Ethernet HWaddr 00:01:6C:DB:24:ED inet addr:192.168.1.200 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36408756 errors:0 dropped:0 overruns:0 frame:0 TX packets:34308001 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1285106723 (1225.5 Mb) TX bytes:3512018401 (3349.3 Mb) Interrupt:17 Base address:0x8000

eth1 Link encap:Ethernet HWaddr 00:01:6C:DB:24:EC inet addr:192.168.1.201 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:434 errors:0 dropped:0 overruns:0 frame:0 TX packets:165 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28255 (27.5 Kb) TX bytes:16142 (15.7 Kb) Interrupt:22

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2263227 errors:0 dropped:0 overruns:0 frame:0 TX packets:2263227 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:260237911 (248.1 Mb) TX bytes:260237911 (248.1 Mb)

netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1

OK, you didn't provide /et/resolv.conf so I don't know if you'r resolver is configured well but this is already a start. I would go into yast, network devices, network card, and delete eth1. Don't worry it doesn't actually remove the card, all that does is remove the ip settings, you can still give it new ip settings and use the nic any time later. Then check netstat -rn again, the default route should be on eth0 now. Reboot just to be a thousand percent sure that it comes up correctly on it's own (so that you can walk away and know that it's ok to reboot from remotely some other day when you need to) Now Just ping 192.168.1.1 If it fails, then move the network cord to the other jack and it probably will work there. Now that you know which jack is which, go to the nearest label maker and pry it out of the unfortunte secrataries resisting hands and label the jacks, right then. :) The default route is "destination: 0.0.0.0" which is where all packets go that did't find a match in some other route, which just means all packets except the few destined for LAN machines. Currently the defult route is set for 192.168.1.1, which is a perfectly good and probably correct address for the LAN side of your NAT router. So far so good. But, you have lied to your machine and told it that there are two equally good ways to reach that address. Via eth0 , and via eth1, when really, only one of those actually works. The routing table above shows that, for whatever reason, the kernel has picked eth1 as the lucky winner of all internet-bound traffic. My _guess_, only a guess still, is that eth1 hs no cable plugged into it. Don't fix it by just moving the cable. It will still be broken even if it seems to work fine from now until the next reboot. Or the next 20 reboots. It will flip-flop at the most carefully crafted inconvenient "random" time that powerful quad core 3ghz xeon can calculate. Once you can ping 192.168.1.1, next try to ping any outside ip addres, by ip not hostname. Well, you could try hostname and it it works then fine, but if itdoesn't work thn you really don't know why yet, connectivity, or merely name resolution. So first ping an outside ip. Your routers own WAN ip is the closest outside ip and is a perfect start. If that works then you now have connectivity. Milestone one. Then look in /etc/resolv.conf It should list at least one valid nameserver. likely suspects would be, 192.168.1.1, since mny routers do dns proxy. and/or whatever the real dns servers are for your net connection. The router will show them in it's settings that it received via dhcp from the isp. The advantage of using 192.168.1.1 is that you never have to worry about updating the linux box if the isp changes their dns servers (which they do now and then) or if the customer changes isp's without even telling you (oh yeah, they never do that....). The router will always receive current settings from the isp, and will always forward for you, and you just point at the router and forget it. The disadvantage of using the routers dns proxy is lot's of times they suck and stop working and the linux box stops being able to resolve hostnames until someone power cycles the router. What really sucks is, just the dns proxy may stop, the rest of the router may still be working fine so no one will power cycle it. all the users desks will be wroking fine. it will be a run around for a while until you remember oh yeah that thing bout the dns settings, yeah, try rebooting the router, yes I know the internet is up fine please just reboot it anyways I promise i'm not a retard and not wasting your time mr annoyed cutomer... heh ask me how I know... Anyways, whichever form of "valid dns server" you put in there, and you can put both actually, up to 3 lines. then try to ping a hostname that you know is outside and that you know responds to ping. www.google.com is one. If that works that's milestone two, name resolution. Now if you still can't ssh in from outside it's things like firewall rules and port forwarding rues in the router. That's really just a first basic step in establishing basic sanity though. You could have sme other problem, but, first stop walking on shifting sands and all that.

...

-- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.11/1553 - Release Date: 7/15/2008 5:48 AM

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org