When i tried to clear all route and IP address information from eth0, I'd get results indicating eth0 successfully cleared. Yet when I'd tried to re-enter a default route, it wouldn't let me do it saying it already existed.

I finally set the router to reserve the address and then set /etc/conf.d/net to

Code:

config_eth0="dhcp"

I watched it reboot several times. The messages are normal - i.e. query the router for an IP assignment, receive the reserved IP, query the network to see of anyone else is using this IP address. Timeout and accept the IP address. It's either right at the last steps of this process or it's one of the follow on boot processes which seem to turn everything pear shaped. I'm almost thinking it's at the end of the "dns_servers" command. /etc/resolv.conf seems to get updated properly. It's after that that I can no longer see router.

The other thing is that I don't seem to be able to completely clear all the route entries. After I think the entries are cleared, I go back to re-add routes. Then I get messages telling the route I want to add is already there. I've been having to reboot each time in order to test different approaches. Same goes for the arp cache. The issues I'm having with the two problem PCs could be table entries not being cleared properly. I need to find out more about where the tables are stored.

When I google RTNETLINK messages, what I find are almost always suggestions that there are missing kernel modules. Yet when I see RTNETLINK messages on my problem PCs, it's invariably telling me something about "no such file or directory". I'm beginning to believe the messages I'm seeing have to do with network table entries and possible missing or already existing elements.

I don't think iptables -F should report anything... it only clears all your rules, then you need to test pinging again.

You should always be able to ping the router regardless if you have a default route set, or even if you have the wrong route set. If the wrong route was set, it just means you can't get out of your subnet.

Step one: ensure that both the switch/route and your box are using the same subnet mask.

Step two: stop iptables on your box to ensure that it is not interferring with communication.
IPTAVBLES can be stopped with one of the following depending on what system you are running;

Code:

openrc:
/etc/init.d/iptables stop

systemd:
systemctl stop iptables

Step three: ping from system to router and from router to system to ensure they are talking

Step four: post entire iptables rule set
This can be done using

Code:

iptables -S

Step five: does your router/switch have any settings that would not allow communication between devices?
If it does post those settings

Step six: if ping still is not working with the firewall turned off then post all network settings from both the router/switch and the box.

I know a few posts back you had different masks on both devices.

Step 1:Router is a commercial device provided by Frontier. No changes there. Local switches are/were unmanaged 1G switches. Replaced room switch 3 days ago but no changes in problem behavior. All devices on room switch use same subnet mask: 192.168.1.0/24

Step 2: iptables is not running on any device connected to room switch.

rc-update show list similar results for firelizard and pryogyro. i.e. I don't start iptables/ip6tables at boot up as I don't feel a need for a firewall behind the router.

step 3: I can't ping the router from blaze nor firelizard. I can't ping blaze or firelizard from the router. pryrogyro had no problems in either direction. blaze and firelizard will both talk with the router during boot-up when aquiring their respective reserved IP addresses from the router. They stop communicating with the router sometime during the boot process.

step 4: posted - see step 1

step 5: no such settings {unmanaged switches}. Router configuration has been unchanged for 9 months.

step 6: Oh wow! The router is royally fscked. Going AFK to try to resolve this. Somehow, the router has assigned 4 IP address to blaze and 3 to firelizard. And I can't clear the assignments from admin ... shutting down all computers on net work and rebooting router now. More later._________________People whom think M$ is mediocre, don't know the half of it.

I think it should be OK to assign four different DHCP leases to a specific machine because a client ID is also associated with them, however all four should not be in its arp cache. But you may not be able to view its arp cache..._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed watching?

It turns out the ISP provided FiOS-G1100 Quantum Gateway was the sole source of the problem. When you login to the router via 'admin', there are four different places where you can check to see what devices are connected to the router. These are the ARP table listing {under the Advanced tab}. the DNS Server {under the Advanced tab - list DNS Server known connections}, IP Address Distribution {under the Advanced tab - Connection List} and several different connection lists under Firewall. Depending on which list you're looking at, it may make sense to have multiple entries for a single connected device.

Example: Under port forwarding, the connection list includes all active connections {IP:port#} including those created automatically for UPnP. Think: transmission bittorrent. The connection list also includes all inactive but manually added port forwarding connections as well.

Of interest here is the DNS Server Connection Listing. It is supposed to be a listing of all router IP assignments via DHCP plus all manually defined static connections. Unless the client is doing IP address aliasing, there should never be more than a single IP address per client in this listing. For my client PC 'blaze', there were 4 IP addresses listed. One was the reserved static IP address {201}. Two were router assigned IP addresses {19 + 25}. These three addresses all had the same host name of 'blaze'. The last IP address {153} was a amalgamation of two different samba server host names apparently when I changed /etc/samba/smb.conf on that PC. For my set up, the router should only ever have a single IP address for 'blaze'. It is interesting to note that the reserved static IP address never appeared in the ARP table. Unfortunately, it didn't occur to me until after I forced a factory reset of the router to check the ARP table for one of the bogus IP addresses.

Behaviorally, upon booting, blaze would properly negotiate getting an IP address. Upon IP address receipt, the router would apparently only recognize communications from one of the bogus IP addresses. The router basically ignored all packets with the correct IP address in favor of non-existent packets with the wrong IP address. Go figure.

It seems that setting up reserved IP assignments on this router has some potential for getting screwed up.

There is no way, or I couldn't find it, of clearing bad IP addresses that the router thinks it knows about. hence the factory reset. Since I ended up doing a factory reset, I also reconfigured the built-in DHCP and reduced it's dynamic IP assignment range. I simplified my devices needing static IP addresses to manual self assignment. I'm hoping this avoids the router confusing itself in the future. Only my boxes and the printers need static assignment.

Also of note: the RTNETLINK messages have disappeared from both computers. The usual recommendation that a kernel module didn't properly load was misleading in this case. I'm going to guess that once the router decided not to talk to the assigned address, this may have left something not properly set in the data used by the nic driver in the kernel. I recall from my days of installing multiple nics with the same chip that the data the kernel loaded could be funky if the nics weren't initialized correctly. This was one of the reasons why we used to compile the nic drivers as modules instead of compiling them in directly. Basically, I'm suggesting the driver got properly loaded but it's working data structure got crapped at the end of initial negotiation with the router.

To be honest, I've never before seen a built-in DHCP daemon in a router do unasked for multiple IP assignments for a single device. Note these were not simultaneous assignments but sequentially happening through prior assignments never being expired. I consider this to be multiple bugs with the router.

To be honest, I've never before seen a built-in DHCP daemon in a router do unasked for multiple IP assignments for a single device. Note these were not simultaneous assignments but sequentially happening through prior assignments never being expired.

While tricky, yes, now that youve identified the source as your ISP provided router, it is worth noting that a good router (yes better ones exist) can do a lot to improve not just the kind of trouble here you have with lower level communications involved in connections over LAN, but additionally it could improve usability, security and even provide superior results in performance too.

Quote:

I consider this to be multiple bugs with the router.

I used to experience some “incompatibility” in the past with the isp provided equipment from Verizon but that was in the olden days of dsl routers. (I cant say i am shocked though they are doing some funny stuff with their equipment). Calling it buggy though may not actually be the most accurate as is likely these are limited aspects or features provided for low price and production costs. I suggest that you go by a new Router to improve things, when it comes to managing connections,, since a switch is only going to perform up to the capability of the router anyhow and it is the Router that needs to make up and processes the basic rules for routing on your network.

I used to experience some “incompatibility” in the past with the isp provided equipment from Verizon but that was in the olden days of dsl routers. (I cant say i am shocked though they are doing some funny stuff with their equipment). Calling it buggy though may not actually be the most accurate as is likely these are limited aspects or features provided for low price and production costs. I suggest that you go by a new Router to improve things, when it comes to managing connections,, since a switch is only going to perform up to the capability of the router anyhow and it is the Router that needs to make up and processes the basic rules for routing on your network.

Yeah, I can second this, routers trying to be "clever" and tripping over themselves in the attempt to make them easier to use, all on hardware worth less than the cost of shipping it to you. Do yourself a favour, go out and buy something, er, nice.