LAN devices lose connectivity?

[tomilius]

Thanks to everyone who took the time to review this information. The problem has, at last, been isolated to the MN-710 (Microsoft Wireless G USB 2.0 Adapter). Sorry for not figuring that out sooner. Anyway, do not buy it.

UPDATE: More is now known about exactly what this issue is... unfortunately, I don't know how to solve it. See the later posts.

I've noticed this a lot lately in the ASUS firmwares (1.9.2.7 on, I believe, even the latest betas). For example, I'll ping a local host name (LAN or WLAN, no difference) and it won't be able to resolve it. Or I'll try to connect via remote desktop to that computer with it's IP address and it will fail. But once I ping it, connectivity is regained...

Or I'll have my Pocket PC ping my desktop computer. It will have "request timed out" all of the time, and I won't be able to connect to listen to the music stream. The solution is to ping the Pocket PC from my desktop computer. Then all of the sudden, the Pocket PC's own pings will go through and it will be able to connect again.

This is very weird... It seems to have already been addressed in the custom firmware one way or another, but I don't see it mentioned in the FAQ. Is there anything fundamental I'm doing wrong? It's as though a device has to ping another one before it can gain access.

Let me reiterate that it doesn't have anything to do with problems with host name resolution, that's just a result of the issue.

Has anyone else experienced anything so weird?

[Oleg]

Do you run software firewall?
LAN to WLAN and WLAN to LAN traffic is not filtered by wl500g...

[tomilius]

Well, yes, but this problem doesn't seem to occur with custom firmware. Let me restate it:

WLAN and LAN are interchangeable here. I'm speaking of this as the Local Area Network as a whole.

There often comes a time when devices on the LAN seem to become separated from each other. They can't access any services on each other unless one of them pings the other one.

So say there's an FTP server running on Computer B. Computer A tries to connect to it and it fails. Computer A pings Computer B. Computer A gets a response and is then able to connect to the FTP server.

The software firewall log shows nothing about denying anything on the LAN...

UPDATE: Occured again. It doesn't only occur with the Pocket PC but it's observed most with it. Can't connect to streaming server. Can't even ping from Pocket PC to the streaming computer. Can access the web and everything else though, including other network computers. I closed the firewall too. The only way to get it working was to ping the Pocket PC from the streaming computer. Then everything was back to normal, the Pocket PC could ping the streaming computer and connect, etc. Here's a visual order of things (the names don't suggest connections are attempted with host names, I use the IP address for pinging or connecting):

PPC->THOMAS CONNECT: FAIL
PPC->THOMAS PING: FAIL
THOMAS->PPC PING: SUCCESS
PPC->THOMAS CONNECT/PING: SUCCESS

UPDATE: Here's something ELSE weird. Out of the 4 computers in my network, only two of them can successfully ping their own IP addresses:

192.168.1.10 (wireless streaming computer): Request timed out to self (192.168.1.10).
192.168.1.11 (directly connected): Request timed out to self (192.168.1.11).
192.168.1.12 (wireless): Success to self (192.168.1.12).
192.168.1.20 (pocket pc): Success to self (192.168.1.20).

Other machines can ping those that can't ping themselves just fine. For example, any computer but mine (192.168.1.10) can ping 192.168.1.10 successfully... Uh... yeah. Odd. Seems like an ASUS issue to me.

Sometimes complications can occur in which things get twisted around so when a device can't ping another one it has to connect to it in order to gain the ability to ping. Don't ask me. It's too confusing for me.

[Oleg]

The pinging own address please be sure, that this address is actually used by this computer. Run ipconfig to check this.
And it should be able to ping own address - if it does not - you've local firewall issue. Pinging own address does not produce any network traffic at all.

[tomilius]

Oh, doh. That's correct, thanks. Outpost Firewall Pro blocks self-pinging. I didn't think it produced any network traffic but I was unsure :-/ Forgot that the other computers used a DIFFERENT software firewall (ZoneAlarm).

The problem mentioned here still exists in ASUS firmware for me (the other one), so even though 1.9.3.5 fixed WPA-PSK: TKIP issues (or very much seemed to), I'm back to 1.9.2.7-3c with WEP.

[tomilius]

Just an update here. This problem exists everywhere. I no longer have a firewall on my main machine which the Pocket PC connects to for music, yet the strange issue of it not being able to connect to the LAN address occurs until this computer pings it. Here's another example:

PPC -> LAN MINE [connect] FAIL
PPC -> LAN MINE [ping] FAIL
PPC -> WAN IP [connect to ports forwarded to MINE] SUCCESS
PPC -> LAN MINE [connect] FAIL
PPC -> LAN MINE [ping] FAIL
LAN MINE -> PPC [ping] SUCCESS
PPC -> LAN MINE [connect] SUCCESS
PPC -> LAN MINE [ping] SUCCESS

So again, in other words, when the Pocket PC for some obscure reason loses connectivity with my computer (and other computers randomly lose "connectivity" with each other), the solution is pinging from one to the other. If pinging from comp A to comp B fails, pinging from comp B to comp A will be a success and solve any further connection problems from A to B.

That should make this disgusting problem perfectly clear... not that I demand special attention or anything, but just in case anyone has a spark of genius and says, "I know what that is!"

[brubber]

If you use host names instead of IP adresses to establish your connection / or ping it may be a DNS problem. If so you may try to establish your connections using IP adresses rather then using DNS or NetBios names. (so instead of connecting to "\\mypc\folder" or "\\mypc.mynetwork\folder" use "\\xxx.xxx.xxx.xxx\folder" and instead of "ping mypc" or "ping mypc.mynetwork" use "ping xxx.xxx.xxx.xxx").

If this doesn't work you may use a utility like traceroute (tracert) to locate the problem and work from there to find a solution

Unlikely but also possible are duplicate MAC or IP adresses in your network.

[tomilius]

If you use host names instead of IP adresses to establish your connection / or ping it may be a DNS problem.

Thanks, but...

Let me reiterate that it doesn't have anything to do with problems with host name resolution, that's just a result of the issue.


If this doesn't work you may use a utility like traceroute (tracert) to locate the problem and work from there to find a solution

Unlikely but also possible are duplicate MAC or IP adresses in your network.
Couldn't be deliberate duplicate MAC or IP addresses, but it wouldn't surprise me if the router, with all its connectivity problems, believed that was true until the pinging of the IP address occured. E.g., my computer connects but loses connectivity randomly and perhaps the router doesn't realize this...

Thanks for the help. :) Problem not solved though.

[brubber]

Tomilius, sorry, did'nt read your first post properly.

Did you try ping -t on one of the machines that loses connection? Let it run for a long time and then Ctrl-Break or Ctrl-C for stats.

did you think of or try the following possibilities?

a bad NIC somewehere in your network causing the problem (broadcast storm)

Virus or Trojan on one of your machines

there are also a number connectivity issues associated with WXP SP2. If you recently upgraded to SP2 this may also be worthwile investigating.

does the problem also occur with your WAN disconnected?

reset TCP/IP stacks

disconnect your machines one by one to check if the problem is related to a specific machine.

use ethereal on one or more of your systems to get some more info

last but perhaps not least, did you try an older firmware like 1.8.1.9 or even 1.6.5.3 (to rule out firmware problems)?

[tomilius]

That's a hefty list of suggestions!

1. Tried it. Every night I would do a ping -t 192.168.1.1 > c:\router.log ... There were usually about 15 "Request timed outs" in 6 hours... I'd guess... But this is straying to my troubleshooting for another problem I've had...
2. Yes, I did think of them and try them.
3. I only have 2 wireless computers "constantly" connected (actually only one is constant, the other goes off at night, under which circumstances the one left on still exhibits the issue).
4. *thinks back on hours spent on making sure everything is perfectly secure and immaculate* Definitely not.
5. Not a recent upgrade; I've had it.
6. If it did I'd take the router back so it's not worth it to try for the time being.
7. Yes, I do.
8. See #3--this is not a likely possibility.
9. Maybe I'll try that ethereal...
10. Older firmwares caused more problems than they solved, in actuality (other than the increased connection drops caused by the lowered strength in the 1.9.2.7 series).

Thanks for offering so many helpful possible solutions. :) Unfortunately, I've already tried most of them.

It happens in ALL firmwares.

I think I'm just going to give up and see if the problems continuously occur with this new long-awaited 6dBi omni-directional antenna.

[tomilius]

UPDATE: AH-HAH! After all of this time, I've isolated the problem! If only I had a solution... 192.168.1.10 (Thomas, my computer) does not receive broadcasts to the MAC address ff:ff:ff:ff:ff:ff like the other computers do when this issue decides to occur... (unless they're from itself). Why? Could it be that the router decides not to send them or... what in the world is happening?

Sorry for posting so much but I really need help with this. Here's a new log from iptraf with MAC addresses replaced for understanding (and privacy). Cynthia is my sister's computer, PPC is the Pocket PC, and Thomas is my computer. Once I cleared my computer's ARP cache and ping'd Cynthia, my Pocket PC finally realized my computer's MAC address somehow.

I tried ethereal, too. As the Pocket PC struggles to get my computer's MAC address, nothing shows up in ethereal (and it's configured correctly to capture all ARP packets) when this problem is occuring, placing the blame on the router ?


23:47:39; ******** IP traffic monitor started ********
23:47:48; ICMP; eth2; 60 bytes; from 192.168.1.10 to 216.109.112.135; echo req
23:47:48; ICMP; eth2; 60 bytes; from 216.109.112.135 to 192.168.1.10; echo rply
23:47:49; ICMP; eth2; 60 bytes; from 192.168.1.10 to 216.109.112.135; echo req
23:47:49; ICMP; eth2; 60 bytes; from 216.109.112.135 to 192.168.1.10; echo rply
23:47:53; ARP request for 192.168.1.12; eth2; 84 bytes; from 00THOMASMAC0 to ffffffffffff
23:47:53; ARP reply from 192.168.1.12; eth2; 40 bytes; from 0CYNTHIAMAC0 to 00THOMASMAC0
23:47:53; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:47:53; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:47:54; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:47:54; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:48:09; ARP request for 192.168.1.20; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:09; ARP request for 192.168.1.20; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:10; ARP request for 192.168.1.20; eth2; 132 bytes; from 000PPCMAC000 to ffffffffffff
23:48:12; ARP request for 192.168.1.1; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:12; ARP reply from 192.168.1.1; eth2; 40 bytes; from 00ROUTERMAC0 to 000PPCMAC000
23:48:17; ARP request for 192.168.1.20; eth2; 40 bytes; from 00ROUTERMAC0 to 000PPCMAC000
23:48:17; ARP reply from 192.168.1.20; eth2; 40 bytes; from 000PPCMAC000 to 00ROUTERMAC0
... (many duplicates)
23:48:38; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:39; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:41; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:48:42; ARP request for 192.168.1.10; eth2; 76 bytes; from 000PPCMAC000 to ffffffffffff
23:48:44; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
... (many duplicates)
23:49:01; ARP request for 192.168.1.10; eth2; 132 bytes; from 000PPCMAC000 to ffffffffffff
23:49:03; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:04; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:06; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:07; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:09; ARP request for 192.168.1.12; eth2; 40 bytes; from 00ROUTERMAC0 to 0CYNTHIAMAC0
23:49:09; ARP reply from 192.168.1.12; eth2; 40 bytes; from 0CYNTHIAMAC0 to 00ROUTERMAC0
23:49:09; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:10; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:10; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:10; ARP request for 192.168.1.10; eth2; 84 bytes; from 000PPCMAC000 to ffffffffffff
23:49:11; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:11; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:12; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:12; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:12; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:13; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:13; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:13; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
23:49:14; ARP request for 192.168.1.1; eth2; 132 bytes; from 00THOMASMAC0 to ffffffffffff
23:49:14; ARP reply from 192.168.1.1; eth2; 132 bytes; from 00ROUTERMAC0 to 00THOMASMAC0
23:49:14; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:14; ARP request for 192.168.1.20; eth2; 40 bytes; from 00THOMASMAC0 to ffffffffffff
23:49:14; ARP reply from 192.168.1.20; eth2; 40 bytes; from 000PPCMAC000 to 00THOMASMAC0
23:49:14; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:16; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:16; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:17; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:17; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:18; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:18; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:19; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:19; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:20; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:20; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:20; ARP request for 192.168.1.12; eth2; 40 bytes; from 00THOMASMAC0 to ffffffffffff
23:49:20; ARP reply from 192.168.1.12; eth2; 40 bytes; from 0CYNTHIAMAC0 to 00THOMASMAC0
23:49:20; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:20; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:21; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:21; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:21; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.12; echo req
23:49:21; ICMP; eth2; 60 bytes; from 192.168.1.12 to 192.168.1.10; echo rply
23:49:22; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:22; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:23; ICMP; eth2; 60 bytes; from 192.168.1.20 to 192.168.1.10; echo req
23:49:23; ICMP; eth2; 60 bytes; from 192.168.1.10 to 192.168.1.20; echo rply
23:49:27; ******** IP traffic monitor stopped ********

Analyzing that along with the information I have given, one can see that my computer does not get the ARP request for some odd reason and never actually replies to it. I don't understand how the Pocket PC was ever able to start communication. Once communication is re-established, it takes a little while for it to "go away" again, so I turned the Pocket PC off and back on and ping'd Thomas and saw this in iptraf:


Tue Mar 22 00:00:15 2005; ARP request for 192.168.1.10; eth2; 40 bytes; from 000PPCMAC000 to ffffffffffff
Tue Mar 22 00:00:15 2005; ARP reply from 192.168.1.10; eth2; 40 bytes; from 00THOMASMAC0 to 000PPCMAC000

What I want to know is why my computer is not getting this ARP request when this problem occurs... (because it's not ignoring it, it's just not getting it at all)

Here's another incident--this time it occured after I "repaired" Cynthia's connection for testing purposes, essentially causing it to lose its arp cache, disconnect, and reconnect. It's wireless too.

I think this might be the reason the connectivity starts again when I ping an unknown address, even if it's not the Pocket PC's: it has to send an arp request out to every computer, and maybe they pick up its MAC address that way. However, it's clearly visible above that under certain conditions it can receive and reply to an arp request, and under others it can't.

I have yet more info. Using ethereal on my and my sister's computers, I noticed that MY computer Thomas is not getting a lot of broadcasts to the broadcast MAC address whereas my sister's computer (also wireless) is, and I don't know why. .. Help?

TEMPORARY SOLUTION: I'm really hoping somebody can help me out with this one, but for now I have it set up to ping 192.168.1.254 every 5 seconds, thereby sending out an ARP broadcast looking for it every 5 seconds (though it doesn't exist) so that new devices can be notified of 192.168.1.10's MAC address when it doesn't respond.

[tomilius]

Alright. My temporary solution didn't work for long, but it's all the MN-710's fault. Boooo. See first post. This thread is done.