Results 1 to 12 of 12

Thread: LAN devices lose connectivity?

  1. #1

    Machine Stops Receiving ARP Requests at Random

    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?
    Last edited by tomilius; 26-03-2005 at 23:51.

  2. #2
    Join Date
    Dec 2003
    Location
    Russian Federation
    Posts
    8,353
    Do you run software firewall?
    LAN to WLAN and WLAN to LAN traffic is not filtered by wl500g...

  3. #3
    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.
    Last edited by tomilius; 26-02-2005 at 22:00. Reason: Update

  4. #4
    Join Date
    Dec 2003
    Location
    Russian Federation
    Posts
    8,353
    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.

  5. #5
    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.

  6. #6
    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!"

  7. #7
    Join Date
    Sep 2004
    Location
    NL
    Posts
    206
    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.
    Last edited by brubber; 09-03-2005 at 01:15.
    Brubber

    WL-500g, WL-138g, WL-160g

  8. #8
    Quote Originally Posted by brubber
    If you use host names instead of IP adresses to establish your connection / or ping it may be a DNS problem.
    Thanks, but...
    Quote Originally Posted by tomilius
    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.
    Quote Originally Posted by brubber
    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.

  9. #9
    Join Date
    Sep 2004
    Location
    NL
    Posts
    206
    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)?
    Brubber

    WL-500g, WL-138g, WL-160g

  10. #10
    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.
    Last edited by tomilius; 22-03-2005 at 05:54.

  11. #11
    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 ?

    Code:
    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:

    Code:
    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.
    Last edited by tomilius; 22-03-2005 at 05:47.

  12. #12
    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.

Similar Threads

  1. USB audio devices
    By tommyb in forum WL-500g Q&A
    Replies: 4
    Last Post: 03-05-2005, 15:02
  2. Mounting USB Devices
    By Dirg in forum WL-500g Q&A
    Replies: 0
    Last Post: 26-02-2005, 19:58
  3. DNS and connectivity
    By Rytmeboksen in forum WL-500g Q&A
    Replies: 3
    Last Post: 04-02-2005, 19:22
  4. Replies: 0
    Last Post: 29-07-2004, 14:08
  5. Connecting other usb-devices?
    By Snigel in forum WL-500g Q&A
    Replies: 4
    Last Post: 17-12-2003, 10:06

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •