Yes, that's a more accurate description.

I moved it to a higher address just in case, but still no dice.

Yes, it's an Actiontec MI424-WR that (according to the docs) optionally supports 1 Gb/s, but obviously my router doesn't support that. The ethtool full output does indicate that the Advertised/supported link modes go up to 1000baseT/Full (which agrees with the motherboard specs), but the Link partner advertised link nodes only go up to 100baseT/Full.

The cable had been used previously for another PC. I just connected a laptop to it, disabled the WiFi connection and verified that the cable is good.

Do you have any liveCD to test the connection? Just to make sure it is not your installed Linux that is acting up.

Assume that hardware is good. Let's see where packet is lost.
1)Just listen eth0 using tcpdump, execute "tcpdump -i eth0"
2)Capture packet when ping default gateway, execute same command, "tcpdump -i eth0"

I've never looked at tcpdump output before, so I'm not sure what is significant. Here is a summary:

That last IP address is one of the ISP dns-nameservers.

ARP handshake is OK. But ping is failure.
You need capture 192.168.1.4 ping on gateway. Ping reply is lost.

Haven't had much time to look at this. I presume that capturing ping "on gateway" means running tcpdump on the gateway/router, or is there some other technique? I can log on to router via an http app provided by Verizon and it can see the box running Linux Mint (192.168.1.15--reassigned static IP to avoid conflict with other devices) and I can ping 192.168.15 from the app (and it fails), but that is about the extent of what can be done from/on the router/gateway.

I'm also considering installing another distro, such as Ubuntu or Debian (which I'm more familiar with), to see if they have the same problem.

If capturing packet on gateway is difficult, you can ping another machine on the network to debugging.

I had already pinged another machine (the one that I'm writing this on) and it works fine. I can also ping a Windows laptop connected by reusing the same ethernet cable as the Mint machine. So, if there's something wrong it's most likely on the latter. As I mentioned earlier (14 Feb), I suspect it's because avahi-autoipd runs and adds the link-local address.

If the machine can ping another machine, that means that the machine has problem with gateway only. Now you might be right, installing another Linux distribution.

I think my previous response may have been unclear. From gateway/router, I can ping (a) Debian machine, (b) Windows laptop connected either via wifi or using same ethernet cable that I use to connect to Mint machine and (c) other devices but not (d) Mint machine. From Debian machine, I can ping gateway/router, laptop and other devices, but not Mint box. From Mint machine, I can't successfully ping anything (except occasionally a single ping to the gateway), as I understand because of the link-local route added by avahi-autoipd.

If so, you can ping Debian machine to find out what's going on. The link-local route might cause the issue but first packet of ping can go out on right interface. We need more information to isolate issue if you want.

I tried installing Debian Jessie and got some clues. While detecting network hardware, the install process complained that it couldn't find rtl_nic/rtl8168g-2.fw. From what I read, this is a non-free driver and is not included in the standard Debian release. So I tried installing from firmware-8.3.0-amd64-i386-netinst.iso (which includes the firmware-realtek package which has the missing driver). The very first time I tried the install from this netinst release it managed to configure DHCP automatically, but then I ran into an unrelated problem. I tried a couple of times more but it was unable to configure DHCP automatically or successfully configure with a static IP. I finished a mininal install anyway and lspci says the Ethernet controller is being handled by the r8169 driver. Some other discussions on LQ suggest installing the driver mentioned at the beginning, so that's what I'll try next.

Firmware run on chip and driver run on CPU. You need both.

Finally fixed it, mostly by following the instructions in http://djlab.com/2010/10/fixing-rtl8...debian-ubuntu/ . First downloaded the latest Linux driver from http://www.realtek.com.tw/downloads/...etDown=false#2 , version 8.041.01. Copied it over to /usr/src on the machine (where I had reinstalled LinuxMint 17.3), and built and installed the r8168.ko module. The "make install" didn't seem to work at first (some message about a signature IIRC), and even though I used at first I got "Access denied". After rebooting and becoming root, the blacklist conf was accepted. "update-initramfs -u" and another reboot finally did the trick. FWIW, the dkms approach also failed at the "install" step for the same signature problem.