Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My wireless fails from between some minutes after being connected to half an hour or more.

Symptoms:

  • new pages not opening
  • downloads already in progress continue
  • ping 8.8.8.8 not working

The "fix" is easy (lasts for a random amount of time):

$ sudo arp -d 192.168.1.1

This solution does not make any sense, since I've checked and it is not ARP poison.

Any ideas on why this happens?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms

Wireless Router: ZonHub 1.0 (Hitron BVW3653 Board with customized Jungo's OpenRG, provided by my ISP)



EDIT May 1, 17:12 UTC:

$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0

As I had said, not ARP poison.

NOTE1: I can only access a webpage on my router, as everything else is locked down by the ISP.

share|improve this question
    
What does the ARP entry look like before you delete it? And what does it look like after a few successful pings? And are you using a secure WiFi encryption mode? (Otherwise, you can accidentally connect to someone else's WiFi network where the hardware address is different.) –  David Schwartz Apr 30 '12 at 11:44
    
I second @DavidSchwartz's questions. Also, next time you're in the broken state, check what the router has as an ARP mapping (if any) for your client. –  Spiff Apr 30 '12 at 17:28
    
Also, what is your current IP settings? Please update in question. –  onxx Apr 30 '12 at 21:30
    
Added requested info; I'm using WPA2-PSK with AES; I can't access any ARP mapping on the router: I have no access to a console on it. –  Pedro F. May 1 '12 at 17:28
    
ok, thanks for the updated info... Also please state your IP gateway(I'm assuming its 192.168.1.1) and DNS servers. On the router web page do you see a routing table? –  onxx May 2 '12 at 22:05

1 Answer 1

up vote 1 down vote accepted

This answer is going to be all guesswork, I have no idea if this is actually the cause, but...

When you delete the router from your ARP table, your computer is forced to send an ARP packet the next time it wants to send any packet to the router. I can guess that this ARP packet fixes whatever is broken in the router's ARP table, since in the example you posted your computer's ARP table seems to be fine (the same before and after "fixing" it).

I am guessing that the router's ARP table, were you able to look at it, would show "(incomplete)" instead of your computer's MAC address (try pinging a nonexistent LAN address for an example of how it looks like). It would get to that state if the ARP entry in it expired, it broadcast an ARP packet, and that broadcast packet never reached your computer (or the response packet never reached the router). Your ARP packet completes the entry and it can send IPv4 packets to your computer again.

Now, why would that happen? I can think of two possible causes. A misconfigured firewall on either the router or your computer (which I think is improbable), or a problem with the broadcast from the wireless router.

Broadcast packets on the 802.11 standard are somewhat problematic. Since they are directed to all associated stations:

  • They are not acknowledged, thus the AP cannot know whether they were received. This means a single misplaced burst of static can kill a broadcast packet.
  • They have to be sent at a rate all stations can hear. The AP cannot use the best rate found by its rate control algorithms. This usually means a much lower rate, from the basic rates of the BSS. This uses more airtime, but helps with the previous problem (lower rates are usually somewhat more robust).
  • Since the same packet should be able to be decoded by all associated stations, they cannot be encrypted with the station's individual key. Instead they have to be encrypted with a separate group key, which all associated stations know. This group key is periodically rotated (otherwise stations which left the network could still decode broadcast packets).

I have personally seem mysterious failures related to this last point. An access point I once configured came with the group key interval disabled. "This is dumb", I thought, "why would they disable that security feature?", and set it to one hour. After some time fixing intermittent wireless connection problems which could be solved by pinging from the correct side (I do not recall anymore if it was from the wired or the wireless side - I had ssh access to the firewall, and I recall it was an ARP problem), I had an insight and thought, "Ah, THAT is why it was disabled by default, it is probably buggy on that access point firmware and they set it to zero as a last-minute fix", set it back to the default, and the problem disappeared.

I have no idea if that is your problem; the manufacturer is completely different, and you probably never touched such an esoteric setting.

The next thing you could try would be to run a sniffer when the problem happens, to see which packets are being exchanged. If you have a second computer, you could plug it on the router's ethernet LAN ports and run a sniffer on that too at the same time (to see if my hypothesis of an ARP broadcast visible on the LAN but not on the wireless has some merit).

And I have no idea how would downloads still continue if my hypothesis is true. Perhaps it somehow caches the MAC address in the TCP connection state?

share|improve this answer
    
Thank you for the time you took to answer! I have WiFi working reliably now (changed channel and IP range) so I won't be able to verify your theory using a packet sniffer for now, so I'm going to accept the answer even without verification, but I'm guessing your theory is right :) –  Pedro F. Jun 2 '12 at 12:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.