Solaris/UNIX/networking experts, help me figure this out...

[SlowToady]

I just copied and pasted this, since I cross posted in the Solaris forums @ sun.com

----
Hi guys,

I've got a Solaris 10 (on x86) networking issue I just can't resolve. I setup a Linksys WRT54GS as an Ethernet Bridge. I turned DHCP on the Bridge off, since address are handed out from the other router. Bridge configuration:

IP: 192.168.1.254
Netmask: 255.255.255.0
Gateway: 192.168.1.1 <--this is the wireless router
DNS: 74.128.17.114

SPI firewall is turned off on the Bridge.

I have a Windows XP client plugged into the Bridge receiving settings via DHCP. It works perfectly.

However, the Solaris 10 machine plugged into the Bridge, doesn't work. I first tried it via DHCP, and it seemed to have picked up the correct settings, but I couldn't connect to the Internet or any remote hosts. In fact, I couldn't even ping the DNS server listed above! I figured I'd give it a shot with static settings, so I re-configured with the following settings:

IP: 192.168.1.104
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 74.128.17.114
hostname: unknown

These are the same settings that Windows XP reported (obviously the IP didn't end in 104). I still cannot access the Internet, or any remote hosts, or ping my DNS servers. I can, however, access the Bridge and wifi router both over the web and via telnet/ssh.

I'm really pretty confused here, it should just work. Is there some obscure setting somewhere I don't know of, or some special way it has to be setup for use behind a Bridge?

Thanks in advance,

~Slow

[svandamme]

does the router make a high pitch squeeking sound?
my linksys did, and it meant it was broken...

it did that from the start and i returned it to sender, and got me a d-link instead

[Mr_Wizard]

What does your /etc/nsswitch.conf file look like?

[SlowToady]

Stijn, nope...it seems to work perfectly...with the XP computer connected...

Mr.Wizard, here you go

# cat /etc/nsswitch.conf
#
# Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)nsswitch.files     1.14    06/05/03 SMI"

#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

passwd:     files
group:      files
hosts:      files
ipnodes:    files
networks:   files
protocols:  files
rpc:        files
ethers:     files
netmasks:   files
bootparams: files
publickey:  files
# At present there isn't a 'files' backend for netgroup;  the system will
#   figure it out pretty quickly, and won't use netgroups at all.
netgroup:   files
automount:  files
aliases:    files
services:   files
printers:       user files

auth_attr:  files
prof_attr:  files
project:    files

tnrhtp:     files
tnrhdb:     files
#

# route -p show
persistent: route add default 192.168.1.1 1
#

# netstat -nr

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
192.168.1.0          192.168.1.104        U         1          7 gani0
192.168.1.0          192.168.1.1          UG        1          0
224.0.0.0            192.168.1.104        U         1          0 gani0
127.0.0.1            127.0.0.1            UH        2         39 lo0
#

# cat /etc/defaultrouter
192.168.1.1
#

[masraum]

Well, if you can ping the local router, but not anything past the router, normally, I'd say that the default gateway isn't configured.

Can you do a traceroute to 4.2.2.2 and provide the results?

If connectivity to local devices is working, then it's just ARP working. To get past your default gateway, the Solaris host needs a default gateway, you already have that. The next thing that needs to happen is that the default gateway will probably be translating (NAT) the 192.168.1.104 address to whatever it's outside address is (assigned by the ISP). If the .104 address isn't translated, then nothing past your router will know where to send the packet to get it back to the Solaris box. Actually, chances are the ISP will block the traffic before it goes anywhere.

If the XP box is working fine then it would seem that the NAT is working ok.

Show us the results of the trace route.

I did once see an issue a long time ago where a specific type of traffic was failing from a UNIX box. The guy swore that it was the router blocking the traffic, but at some point we realized that the TTL of the packets for that traffic had been set to 1 which kept all of the traffic local. Seems highly unlikely to be the problem in this case.

Try setting the address to something different 192.168.1.10 or .200 or .74, whatever.

[HardDrive]

Router setup for MAC filtering?

[SlowToady]

# traceroute 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  1.893 ms  1.406 ms  1.796 ms
 2  74.131.88.1 (74.131.88.1)  11.640 ms  13.882 ms  25.176 ms
 3  74.131.0.153 (74.131.0.153)  14.495 ms  10.560 ms  20.950 ms
 4  74.128.9.245 (74.128.9.245)  121.274 ms  198.776 ms  204.078 ms
 5  144.223.14.229 (144.223.14.229)  24.058 ms  19.913 ms  19.673 ms
 6  144.232.26.69 (144.232.26.69)  34.250 ms  34.685 ms  20.308 ms
 7  144.232.20.3 (144.232.20.3)  21.138 ms  23.312 ms  24.244 ms
 8  144.232.8.114 (144.232.8.114)  24.525 ms  23.554 ms  21.473 ms
 9  4.68.101.66 (4.68.101.66)  19.647 ms 4.68.101.98 (4.68.101.98)  21.247 ms 4.68.101.162 (4.68.101.162)  20.894 ms
10  4.2.2.2 (4.2.2.2)  23.881 ms  18.878 ms  30.957 ms
#

I can even telnet to port 80 of 209.85.171.99 which an nslookup of (on XP client) translates to google.com, but I can't ping google.com. I can ping the 209 address though But I still can't ping my DNS server -or- the XP client. But I can connect from the XP client to the Solaris client with SSH.

Also, check this out...192.168.1.100 == XP client

# traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  *^C#

[SlowToady]

Just double checked that...nope

Originally Posted by HardDrive

Router setup for MAC filtering?

[SlowToady]

Ok..and somehow I just connected via telnet to port 139 of my XP client. Yet I still can't ping it? WTF? Or traceroute to it???

[slodave]

How come your gateway route is not tied to an interface?

# netstat -nr

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
192.168.1.0          192.168.1.104        U         1          7 gani0
192.168.1.0          192.168.1.1          UG        1          0
224.0.0.0            192.168.1.104        U         1          0 gani0
127.0.0.1            127.0.0.1            UH        2         39 lo0
#

[SlowToady]

In Solaris you don't need to explicitly define the interface. I re-did the route with

#route change 192.168.1.0 192.168.1.1 -ifp gani0

to tie it explicitly, but still no dice.

[HardDrive]

Is there some kind of ICMP filtering 'feature' on either of the devices? Oh course thats does not explain the disparity between the XP box and Solaris box......nevermind.

[masraum]

Originally Posted by SlowToady

# traceroute 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  1.893 ms  1.406 ms  1.796 ms
 2  74.131.88.1 (74.131.88.1)  11.640 ms  13.882 ms  25.176 ms
 3  74.131.0.153 (74.131.0.153)  14.495 ms  10.560 ms  20.950 ms
 4  74.128.9.245 (74.128.9.245)  121.274 ms  198.776 ms  204.078 ms
 5  144.223.14.229 (144.223.14.229)  24.058 ms  19.913 ms  19.673 ms
 6  144.232.26.69 (144.232.26.69)  34.250 ms  34.685 ms  20.308 ms
 7  144.232.20.3 (144.232.20.3)  21.138 ms  23.312 ms  24.244 ms
 8  144.232.8.114 (144.232.8.114)  24.525 ms  23.554 ms  21.473 ms
 9  4.68.101.66 (4.68.101.66)  19.647 ms 4.68.101.98 (4.68.101.98)  21.247 ms 4.68.101.162 (4.68.101.162)  20.894 ms
10  4.2.2.2 (4.2.2.2)  23.881 ms  18.878 ms  30.957 ms
#

This proves that you have IP connectivity to the Internet.

XP has a firewall, that's probably why you can't ping it. Also, it's not uncommon for people to disable ping responses on DNS servers. So pinging may not be the best test.

Try defining 4.2.2.3 as a DNS server. I've used that before for testing as well.

It sounds like your biggest problem may be DNS.

[SlowToady]

Wow...stupid XP firewall. I thought I had it turned off. I can now ping and traceroute to the XP client.

You know, it annoys the hell out of me that people disable ICMP, since the RFC explicitly says not to. I guess I can understand why they do disable it, but it's super annoying and doesn't really add any security. But anyway...

Ok so I figured it out as I was writing this reply about how it didn't work...here's how I fixed it.

#touch /etc/resolv.conf
#echo nameserver 4.2.2.3 > /etc/resolv.conf
# cp /etc/nsswitch.dns /etc/nsswitch.conf

Thanks guys!

[svandamme]

you sure it's in bridge mode, and not in client mode

client mode is where the wifi thing basically acts as an external wifi client on ethernet...
it will only take 1 ethernet client as it's no a true bridge mode... i have a netgear i used for that purpose

edit. never mind, just seen the last posts

[masraum]

Excellent. I hate those "It's really simple, it has to work." Problems that pop up from time to time.

[mikester]

Originally Posted by SlowToady

Wow...stupid XP firewall. I thought I had it turned off. I can now ping and traceroute to the XP client.

You know, it annoys the hell out of me that people disable ICMP, since the RFC explicitly says not to. I guess I can understand why they do disable it, but it's super annoying and doesn't really add any security. But anyway...

Ok so I figured it out as I was writing this reply about how it didn't work...here's how I fixed it.

#touch /etc/resolv.conf
#echo nameserver 4.2.2.3 > /etc/resolv.conf
# cp /etc/nsswitch.dns /etc/nsswitch.conf

Thanks guys!

I really hate it when Security experts say to disable ICMP too - ICMP is a requirement for a properly functioning IP network.

Without ICMP you can't negotiate things like MTU size properly, for example if a down stream router has a lower MTU size and the packets that are reaching it are larger than that MTU - without ICMP it cannot negotiate with the other routers or the host sending the data to change the packet size or to fragment the packets. You basically break the network at that point.

Lame.

[KFC911]

Originally Posted by mikester

I really hate it when Security experts say to disable ICMP too - ICMP is a requirement for a properly functioning IP network.

Without ICMP you can't negotiate things like MTU size properly, for example if a down stream router has a lower MTU size and the packets that are reaching it are larger than that MTU - without ICMP it cannot negotiate with the other routers or the host sending the data to change the packet size or to fragment the packets. You basically break the network at that point.

Lame.

They should fix the downstream routers . Seriously, I'd venture that most large company's disable ICMP from passing through their firewalls based upon my experience in corporate america (connecting with lots of other "corporate networks"). I once even had a Security manager adamantly insist upon having DNS disabled on firewalls that connected to our DMZ many years ago...I assured him he would change his mind soon (after beating my head again against the wall), and quit arguing with someone who had no clue...

[HardDrive]

Originally Posted by masraum

Excellent. I hate those "It's really simple, it has to work." Problems that pop up from time to time.

Used to get these bizarre ARP table issues with 3Com switches. They would hold a MAC address for a port, and flushing the arp table did not clear it. You would have to cycle the box to fix it. Yeah, THAT took us a little while to figure out. A server would not communicate when plugged into the port, and we would be staring at the command prompt saying, "Thats just not freaking possible!"

[KFC911]

I've had some REAL headaches over the years with ARP caching issues on Cisco routers causing HUGE networking outages...those can be a bear to find/debug. How come I'm not missing those days ?