John Peel wrote: > > > and route shows that eth0 has two addresses the internal > > > ip as well as the dhcp ip. > > > > "route" doesn't tell you anything about which IP addresses are bound > > to a NIC. It may tell you that a certain IP address is routed via a > > particular NIC, but that doesn't mean that the IP address is bound to > > the NIC. > > I was unaware of how route actually worked but I guess the real issue is > is that route was showing me an uotput similar to this: > > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.1.10 192.168.1.1 255.255.255.0 0 eth0 > 24.217.32.0 * 255.255.240.0 U 0 0 0 eth0 > 127.0.0.0 * 255.0.0.0 U 0 0 0 lo > default ol1-24.217.32.1 0.0.0.0 UG 0 0 0 eth0 > > so while it wasn't telling me actuall information about the nic itself > it was showing me one too many ips. I may still be way off on what this is > actually showing but i was desperate and searching for an answer. It's showing you that you have routes to two different networks (192.168.1.0/8 and 24.217.32.0/12) via eth0, but one of the routes (192.168.1.0/8) is down (no "U" flag). I note that the RH6.2 init.d/network script doesn't call "route add", so it's relying upon "ifconfig" to add the route. Also, it appears that the "ifup" script calls "route add" if it can't find a suitable entry in the routing table, but it doesn't check whether the route has the "U" flag. > > > I have been able to get it to have only the internal ip by restarting the > > > entire machine which should not be necessary. > > > > A reboot will (amongst other things) run: > > > > /etc/rc.d/init.d/network start > > Yes but it would appear that it is also flushing out some other > information regarding the nic because without a reboot running > /etc/init.d/network restart results in the problems above but a reboot > does not. Well, the reboot itself will clear everything (e.g. the routing table) first. > > > the next part isn't so important but once I get machine A to work properly > > > I can ping itself, I can also ping the router but not the outside world. > > > The router can ping itself and the outside world but not machine A. > > > > Does the router have the correct routing information for machine A? > > Not really sure I am still getting started with routing. Well, one of the most common source of problems with routing is neglecting to take care of both directions. > > Are you using any form of NAT (e.g. masquerading) on the router? If > > not, then machine A definitely won't be able to talk to the rest of > > the Internet (it may be able to send packets, but those packets will > > have a source address of 192.168.1.10, so you won't get any replies). > > as of right now my first goal is to set the router up as a masquerading > server. back in 2.2 days I had no problems setting up masquerading which > is why this is so frustrating. I have all of the proper modules loaded > according to lsmod but I really am not sure about having proper routing > setup on the router for machine A. As a sidebar to this I know that > machine B was getting hit from Machine A by looking at /var/log/messages I > see martian errors or something like that and machine As ip address is > listed in the error. (Sorry i can't be more specific but I can't get the > actual error from work.) > > I don't know if this may help to diagnose my problem any more, or if the > conclusion is just that my box is just plain screwy. Again any help is > appreciated. Thanks, -peel I would suggest starting with manual ifconfig/route commands all around. Once you have a configuration which works, then you can figure out how to make the systems' configuration mechanism do it for you. One of the reasons that I don't use tools like linuxconf etc is that I often find that, rather than eliminating the need to understand what's going on underneath, I actually need to undertand both what's going on underneath and how that relates to the program that's trying to do it for me. While RedHat's "init" setup makes things simple for tools like linuxconf, when you want/need to do it yourself, the actual scripts involved are ten times more complex than Slackware's rc.inet1. -- Glynn Clements <glynn.clements@virgin.net> - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
