Can't get outside the subnet

So I recently installed opensuse 11.2 on an old PIII desktop machine. The computer doesn’t have a DVD drive, so I used the net install CD, and pulled the data from another machine on the subject (via SMB/CIFS).

Well, the install went fine… but I am having trouble with networking… I can’t seem to access anything beyond the NAT (beyond the 10.0.0.0/24 subnet).

I first thought that perhaps DNS is the issue, but replacing hostnames with IPs doesn’t make a difference. I then questioned whether DHCP was working correctly (although it seems to work with the other few machines on the subnet). So, I set the machine up with a static IP and static default gateway. That didn’t help. I’ve disabled the firewall… even replaced NICs. No go.

Something with this particular machine has me stumped.

I can browse shares, intranet web pages, etc… I just can’t seem to get outside the subnet. I get “network unavailable”, which to me, implies the routing table isn’t right. But I can’t see anything wrong with it.

I had an old Linksys PCI NIC (using the tulip driver) in there, and tried a 3Com 3c905c in it’s place… no go.

So, at this point, I’m open to suggestions. Any thoughts, ideas?

Thanks in advance

Points to routing if you can ping in/out on the subnet; what does /sbin/route say?

Unless you have some exotic upstream routing restriction (thinking e.g. iptables on router by ip address?)

Well, you did say “any thoughts” !

IG

Sounds like the Gateway address did not get picked up on DHCP, but you said you put it in manually and it still doesn’t work.

I had this same problem with KNetworkManager and never could figure it out. Some folks said to delete /etc/resolv.conf and reboot, but that did not help for me. I ended up changing to ifup and everything works great now.

Okay… so I got some time to address this issue further. I fired it up, popped up a console, typed route waited for more than 10 seconds, and finally go this:


mycomputer:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         10.0.0.1        0.0.0.0         UG    0      0        0 eth0

So I checked YaST again to verify it was set up to use the traditional if-up scripts. According to YaST, yes, was.

So, I explicitly set eth0 up for the gateway (there’s two network cards in it at the moment - one will come out eventually). Anyhow, after YaST had saved the changed I repeated what I’d done before:


mycomputer:/home/jennjoel # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo

Ping an address outside the subnet:


connect: Network is unreachable

So I checked my ifcfg script for eth0 (auto generated by YaST):


BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.0.0.20/24'
MTU=''
NAME='3c905C-TX/TX-M [Tornado]'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
PREFIXLEN='24'

This eventually needs to be on DHCP. I’ve got it on static at the moment to eliminate variables as part of the troubleshooting process.

I also ran ‘netstat -s’, although I’m not that savvy with the output:


mycomputer:/etc/sysconfig/network # netstat -s
Ip:                                         
    1953089 total packets received          
    0 forwarded                             
    0 incoming packets discarded            
    1953082 incoming packets delivered      
    1138180 requests sent out               
    128 dropped because of missing route    
Icmp:                                       
    110 ICMP messages received              
    6 input ICMP message failed.            
    ICMP input histogram:                   
        destination unreachable: 93         
        echo replies: 17                    
    32 ICMP messages sent                   
    0 ICMP messages failed                  
    ICMP output histogram:                  
        destination unreachable: 12         
        echo request: 20                    
IcmpMsg:                                    
        InType0: 17                         
        InType3: 93                         
        OutType3: 12                        
        OutType8: 20                        
Tcp:                                        
    125 active connections openings         
    5 passive connection openings           
    42 failed connection attempts           
    0 connection resets received            
    1 connections established               
    1952756 segments received               
    1137671 segments send out               
    19 segments retransmited                
    0 bad segments received.                
    37 resets sent                          
Udp:                                        
    178 packets received                    
    0 packets to unknown port received.     
    0 packet receive errors                 
    472 packets sent                        
    RcvbufErrors: 0                         
    SndbufErrors: 0                         
UdpLite:                                    
    InDatagrams: 0                          
    NoPorts: 0                              
    InErrors: 0                             
    OutDatagrams: 0                         
    RcvbufErrors: 0                         
    SndbufErrors: 0                         
TcpExt:                                     
    ArpFilter: 0                            
    75 TCP sockets finished time wait in fast timer
    471 delayed acks sent                          
    5 delayed acks further delayed because of locked socket
    Quick ack mode was activated 39 times                  
    41 packets directly queued to recvmsg prequeue.        
    66884 packets directly received from backlog           
    7156 packets directly received from prequeue           
    1762623 packets header predicted                       
    67 packets header predicted and directly queued to user
    TCPPureAcks: 124                                       
    TCPHPAcks: 318                                         
    TCPRenoRecovery: 0                                     
    TCPSackRecovery: 2                                     
    TCPSACKReneging: 0                                     
    TCPFACKReorder: 0                                      
    TCPSACKReorder: 0                                      
    TCPRenoReorder: 0                                      
    TCPTSReorder: 0                                        
    TCPFullUndo: 0                                         
    TCPPartialUndo: 0                                      
    TCPDSACKUndo: 0                                        
    TCPLossUndo: 1                                         
    TCPLoss: 0                                             
    TCPLostRetransmit: 0                                   
    TCPRenoFailures: 0                                     
    TCPSackFailures: 1                                     
    TCPLossFailures: 0                                     
    TCPFastRetrans: 2                                      
    TCPForwardRetrans: 0                                   
    TCPSlowStartRetrans: 1                                 
    TCPTimeouts: 13                                        
    TCPRenoRecoveryFail: 0                                 
    TCPSackRecoveryFail: 0                                 
    TCPSchedulerFailed: 0
    TCPRcvCollapsed: 0
    TCPDSACKOldSent: 39
    TCPDSACKOfoSent: 0
    TCPDSACKRecv: 1
    TCPDSACKOfoRecv: 0
    TCPAbortOnSyn: 0
    TCPAbortOnData: 0
    TCPAbortOnClose: 0
    TCPAbortOnMemory: 0
    TCPAbortOnTimeout: 0
    TCPAbortOnLinger: 0
    TCPAbortFailed: 0
    TCPMemoryPressures: 0
    TCPSACKDiscard: 0
    TCPDSACKIgnoredOld: 0
    TCPDSACKIgnoredNoUndo: 1
    TCPSpuriousRTOs: 0
    TCPMD5NotFound: 0
    TCPMD5Unexpected: 0
    TCPSackShifted: 0
    TCPSackMerged: 2
    TCPSackShiftFallback: 7
IpExt:
    InNoRoutes: 0
    InTruncatedPkts: 0
    InMcastPkts: 162
    OutMcastPkts: 90
    InBcastPkts: 62
    OutBcastPkts: 0
    InOctets: 2741284062
    OutOctets: 72070096
    InMcastOctets: 41932
    OutMcastOctets: 21795
    InBcastOctets: 11570
    OutBcastOctets: 0

It’s clear the machine can’t get outside the subnet, but seems to work beyond that. Any thoughts?

On 11/29/2009 05:16 PM, jasonsbailey wrote:
>
> Okay… so I got some time to address this issue further. I fired it up,
> popped up a console, typed route waited for more than 10 seconds, and
> finally go this:
>
>
> Code:
> --------------------
>
> mycomputer:~ # route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
> link-local * 255.255.0.0 U 0 0 0 eth0
> loopback * 255.0.0.0 U 0 0 0 lo
> default 10.0.0.1 0.0.0.0 UG 0 0 0 eth0

Notice the “default” line.

> So, I explicitly set eth0 up for the gateway (there’s two network cards
> in it at the moment - one will come out eventually). Anyhow, after YaST
> had saved the changed I repeated what I’d done before:
>
>
> Code:
> --------------------
>
> mycomputer:/home/jennjoel # route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
> link-local * 255.255.0.0 U 0 0 0 eth0
> loopback * 255.0.0.0 U 0 0 0 lo

No “default” line. The device does not know how to get to anywhere but
10.0.0.X.

> This eventually needs to be on DHCP. I’ve got it on static at the
> moment to eliminate variables as part of the troubleshooting process.

You failed to enter a gateway. When you give up DHCP, all the little
details will get you. In fact, DHCP is much easier and should be used
first, then switch to static IP.

Right…

I’m aware of DHCP and how it works. But in this case something is going wrong. Either the DHCP client isn’t picking up the info, or the routing table isn’t being updated.

So that is why I went to a static IP configuration. YaST shows the correct gateway address in the network preferences box, but it doesn’t show in the routing table. So there’s something wrong.

Now, I can add the default gateway with the route command, but that doesn’t seem to be doing anything (yes, I’ve added the default route with the route command before). It’s not helping, and besides… I shouldn’t have to do that.

Here’s something else worth mentioning:

My router is performing NAT and DNS masquerading. Port 53 on 10.0.0.1 should be open. On two other computers on the subnet, a scan of port 53 on 10.0.0.1 is open (nmap scan shows it, name resolution works). But on the defunct machine, nmap returns port 53 on 10.0.0.1 is closed.

So I checked iptables on the defunct machine, and all chains are cleared and set to accept.

Now I’m wondering if it’s not jiving with my router. It’s a Linksys WR54T running the latest version of DD-WRT (v24sp1), micro version. I’ve plugged through it, and I don’t see anything, setting wise, that would point to a problem.

But all in all, that routing table on that defunct machine is still out of whack. So I don’t know what to think about all of this (something isn’t adding up), but the routing table is still a definite issue.

Oh, and yes, I do appreciate the help :slight_smile:

I see opensuse is still using dhcpcd instead of IHC’s dhclient. That’s disappointing. I have had a lot of trouble with dhcpcd over the years… dhclient is far more reliable - at least it has been for me. I don’t know dhcpcd is at fault this time, but it has been at fault several times in the past.

Have you tried another network card (other than the ones you have tried). The 905 is rather old and may have a hardware fault (though I can’t imagine one that would cause your problem).

Also you might want to snoop on the DHCP packet exchange to see if the lease is coming in with the correct gateway info.

The machine has a secondary network card (an older Linksys card). It is using the old tulip driver. I get the same results. That tells me it’s probably not hardware.

I could sniff the packets DHCP I suppose… but the fact that it won’t work in a static IP setup makes me wonder if the problem is deeper than that. In my experience, a static IP setup usually works (albeit impractical in the long run) when DHCP fails.

Packet sniffing aside, is there anything else you can think of that would throw the machine off? Also, is there a file I can edit for the gateway info? Is it in one of the /etc/sysconfig/network scripts? I’d be curious if I added the info to the file and rebooted… and if it worked, it would help me know exactly where things are going sour. That, and it’s a relatively simple thing to try.

/etc/sysconfig/network/routes