What's your route table say? it looks like you have two default gateways, so is there a more specific persistent route to both LANs?

You seem to have some crossed wires (figuratively): Your second paragraph says, “One card (Ethernet 3) [is] configured as 10.0.0.2. …. Ethernet 4 [is] configured as 10.1.1.2.” But your third paragraph and your ifconfig output say the opposite.

Worse, you’re a little fuzzy on explaining how 10.0.0.2 and 10.0.0.105 are supposed to communicate. I presume that the two computers are connected to the Buffalo switch with Ethernet cables. You mention that there are “other machines on the wired network”. Can you ping them from 10.0.0.2? If not, then the answer is probably what you already know: the network is flaky. And what is 10.0.0.254? (It might be worthwhile to edit this information into your question.) Finally, are your two route print outputs in the right order?

You should try to solve the "unidentified network" cycling. And you should check if the firewall prohibits answering to ping requests for some network types. Maybe ping requests are filtered on public network and allowed on private network.

Some other things you could try: when IPv4 ping fails, run "arp -a". (This should be done on a device on the same subnet). Or try IPv6 ping ("ping6" or "ping -6"). These may reveal if you have Layer 3 (IPv4-related) issues. Disable firewalls (temporarily). That may be what the whole ("Network 4"/"Unidentified Network" verbiage is related to, so eliminate that potential complexity while troubleshooting). Of course, proper care is essential for any firewall disabling.

@Werner and TOOGAM: You raise the possibility that the failure to ping may be caused by a firewall. How is this consistent with the fact that the problem goes away by itself (i.e., pings start working) after a while (the OP mentions "an hour")?

G-Man - 10.0.0.2 and 10.0.0.105 are not supposed to communicate. I want to keep the wired and wireless networks separate. However, I do want to be able to access both from the dual card machine.

@G-Man - Sorry about the typo. "Ethernet 3" card is configured as 10.1.1.2 and "Ethernet 4" is configured as 10.0.0.2.

@G-Man - Double checked the two 'route print' outputs. The first one is for when the ping works. The second is for when the ping is not yet working.

@G-Man - You ask what is 10.0.0.254. There is no 10.0.0.254 machine. Windows appears to make it the default gateway but 10.0.0.254 cannot be pinged even when 10.0.0.105 can be pinged. Agree isn't a firewall issue because disabling the firewall in the past hasn't helped. In any case, as you say, it fixes itself if given time.

@Werner - Agree should try to solve the "unidentified network" cycling but where do you start? Is there a Windows 8 log I can look at which will tell me what is happening behind the scenes?

Did I miss something? In your route table, why are the metrics different between the route table that works and the one that doesn't? One has a metrics of 21 and the other has a metrics of 31, so something is changing in there somewhere (or maybe the posting is a type-o)?

(1) The question title says, "Cannot ping 10.0.0.105/24 from 10.0.0.2/24". If you want to ping 10.0.0.105 from 10.0.0.2, that means you want 10.0.0.2 and 10.0.0.105 to communicate. (2) When somebody points out a typo in your post, you should not just reply with a comment saying, "Yes, that's a typo"; you should fix the typo.

(3) Your last four big text blocks are ipconfig (failure), ipconfig (success), route print (success), and route print (failure). This is a non-parallel order, which is confusing. (4) Seriously? The wired network has a default gateway that doesn't exist, and you don't think that's worth mentioning or investigating?

@G-man - Sorry I misread your question and then got the comment all wrong. Of course 10.0.0.2 and 10.0.0.105 are supposed to communicate. Both are connected by cable to the Buffalo switch.

@STGdb - You ask "why are the metrics different between the route table that works and the one that doesn't?" I can tell you that it isn't a typo. It is a cut and paste of the 'route type' output in the two scenarios. I don't know why they are different. I guess that is why I am asking you guys.

@G-Man - You say "...wired network has a default gateway that doesn't exist, and you don't think that's worth mentioning or investigating?". Fair enough but please note that the missing default gateway is missing in both scenarios - when the ping works and when the ping doesn't work. As for the investigating - how do you do that? I am not setting that default. Windows appears to have done it for me.

As mentioned in my edited question, nothing I do through the Windows "Windows Network and Sharing Center" sticks. When I go back into the IPv4 properties for Ethernet 4 it always says "Obtain an IP address automatically" and "Obtain a DNS Server address automatically". So there is a contradiction between the IPv4 properties window and the ipconfig output. As I asked above, is there a Windows 8 log I can look at which will tell me what is happening behind the scenes while the problem is resolving itself over time?

@TOOGAM - Please see 'arp -a' output in both scenarios in edited question.

@G-Man : I dunno. My thought is that some change to the firewall rules might occur. I don't mean that the user changed the firewall rules. I mean that if the NIC was being re-initialized (so device manager was flipping it from an unknown device to an initialized device), maybe the firewall software would respond by adjusting the rules because a recognized "Network Card 3" NIC became available, instead of the "Unidentified device" that was in an "identifying" state. 'twas semi-wild speculation, with the idea of simplifying a situation by removing item w/ known potential to add complexity.

@Svet : When you say things are working, your arp table shows nothing for 10.0.0.105. When you ping something without an arp entry, that usually indicates there is no direct link. If you're getting a response, that indicates that it is being routed. When it works, your Ethernet 4 reports DHCPv6 IAID and Client DUID, and your routing tables have 6 additional IPv6 routers related to interface 17, which is Teredo. I know it sounds like I keep talking about IPv6, but Teredo is related to both IP stacks.

I see you've been trying, so I have some more advice to keep plugging away at this. (A) As I said before, do IPv6 pings. (B) Use the % to specify which interface. If IPv6 works, that will help to confirm that the NIC is working in Windows, even if IPv4 routing is not working quite clearly. (C) Also, adjust settings to disable DHCPv6. (D) Finally, sniff NICs to confirm which NIC is used when pings work. If "ping 10.0.0.105" actually goes out Ethernet 3, not 10.0.0.2's "Ethernet 4", we must know. As you get all that carefully documented, hope things will start to make some more clear sense.

@TOOGAM - Double checked 'arp -a' output in the scenario where ping 10.0.0.105 is working and am now getting slightly different output. Please see the edited question. Bottom line is that there is now an entry for 10.0.0.105. ('10.0.0.105 00-02-d1-15-62-7d dynamic')

@TOOGAM @G-Man Can try without firewall tomorrow morning. Cannot do it during work hours. However, tried repeated 'tracert 10.0.0.105' from initial non-working scenario until ping started to work. Pasted output at bottom of edited question. Output appears to implicate the wireless router 'BoB.iiNet [10.1.1.1]' in some way. Any ideas?

@TOOGAM - Felt stupid that first copy of 'arp -a' in the working scenario didn't include a 10.0.0.105 entry. So tested with printer at 10.0.0.11. It had no arp entry until after I pinged and tracerted it. Don't know if that helps but it does explain the difference in the arp output for 10.0.0.105. Presumably I did the arp before the ping.

@studiohack - Can this move back to comments again? The move to chat appears to have killed the discussion. I am still hoping for an answer to the original questions.

Svet : I disagree. studiohack did a good and right thing. I had some concerns about more conversation without clear progress towards an actual resolution/answer. I support studiohack's decision. I have just been slow to respond, and for multiple reasons. First, the conversation was quickly copied, but took a while to "move" (to be deleted from the other page). I didn't want to complicate the moving procedure by adding comments while the move seemed unfinished.

Second, you've been losing my interest because you haven't been following recommendations like showing IPv6 ping results, which may be tell-tale about whether hardware is being operational. Without cooperation of further tests, and sharing the results, this challenging question becomes even more difficult (and borderline impossible) to troubleshoot further. Given the conditions, and results so far, I've begun to doubt my ability to resolve this soon.