2 of 3 PCs on same switch ... [SOLVED]

[dufeu]

[SP2340]

Might I suggest a step by step process for fixing this?

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;

[eccerr0r]

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.

The missing file thing still seems to imply something wrong with kernel or modules or something related...but doesn't make sense if you didn't touch the kernel...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[dufeu]

[eccerr0r]

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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[dufeu]

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.

Problem resolved through factory reset.

I'd like to thank everyone whom offered really excellent advice and suggestions. Everything is running really sweet now.
_________________
People whom think M$ is mediocre, don't know the half of it.

[LIsLinuxIsSogood]

[Ralphred]