Wireless intermittent link break on B2011UAS-2HnD-IN

I have configured my new RB2011UAS-2HnD-IN to act as a router and Wifi AP Bridge.

My MacBook connects wirelessly and surfing on the internet is working.

However, from time to time (every 10 minutes or so), and more frequently when I download a big file, this is what a PING from my MacBook to the router gives :

64 bytes from 10.2.0.1: icmp_seq=3022 ttl=64 time=9.644 ms
64 bytes from 10.2.0.1: icmp_seq=3023 ttl=64 time=4.150 ms
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 3024
ping: sendto: No route to host
Request timeout for icmp_seq 3025
Request timeout for icmp_seq 3026
64 bytes from 10.2.0.1: icmp_seq=3027 ttl=64 time=0.650 ms
64 bytes from 10.2.0.1: icmp_seq=3028 ttl=64 time=0.701 ms
64 bytes from 10.2.0.1: icmp_seq=3029 ttl=64 time=0.644 ms

Whatever channel frequency or Band (G/B/N) I use (I have tried B only, B/G only,…) , TKIP, AES, I still get that link break from time to time.

I also have fiddled with Adaptive Noise Immunity but to no avail.

I have installed a Logging Rule for “wireless, debug” but nothing is logged when that link break takes place.

On a PC connected with a LAN cable, the same PING goes ok without any problems. So the problem only occurs on Wireless clients.

[admin@MikroTik] > interface wireless print advanced 
Flags: X - disabled, R - running 
 0  R name="wlan1" mtu=1500 mac-address=D4:CA:6D:63:00:54 arp=reply-only disable-running-check=no 
      interface-type=Atheros AR9300 radio-name="D4CA6D630054" mode=ap-bridge ssid="Fred Network" area="" 
      frequency-mode=manual-txpower country=belgium antenna-gain=0 frequency=2412 band=2ghz-b channel-width=20mhz 
      scan-list=default wireless-protocol=802.11 rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps 
      supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps 
      basic-rates-a/g=6Mbps max-station-count=2007 distance=dynamic tx-power-mode=default 
      noise-floor-threshold=default nv2-noise-floor-offset=default periodic-calibration=default 
      periodic-calibration-interval=60 dfs-mode=none wds-mode=disabled wds-default-bridge=none wds-default-cost=100 
      wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled bridge-mode=enabled 
      default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 
      proprietary-extensions=post-2.9.25 wmm-support=disabled hide-ssid=no security-profile=WPA 
      disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no 
      station-bridge-clone-mac=00:00:00:00:00:00 ht-ampdu-priorities=0 ht-guard-interval=any 
      ht-supported-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-
                 14,mcs-15,mcs-16,mcs-17,mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23 
      ht-basic-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 ht-txchains=0 ht-rxchains=0 ht-amsdu-limit=8192 
      ht-amsdu-threshold=8192 tdma-period-size=2 nv2-queue-count=2 nv2-qos=default nv2-cell-radius=30 
      nv2-security=disabled nv2-preshared-key="" hw-retries=7 frame-lifetime=0 
      adaptive-noise-immunity=ap-and-client-mode hw-fragmentation-threshold=disabled hw-protection-mode=none 
      hw-protection-threshold=0 frequency-offset=0 rate-selection=advanced multicast-helper=default

Any hint ?

Thanks

U should try another kind of device - Android smartphone etc , windows notebook or Ubuntu - **it-book, **it-phone or another shit device are out of target because everybody knows how awful wi-fi they have.

Thanks a lot, but I really believe that Mikrotik has many happy MacOS clients :slight_smile:

How much is distance between your notebook and router ?

5 meters, I see the router at the other side of my room. I have 3 other MacBooks connected, and they also experience the same problem.

Try bigger distance - you are too close.

Hehe, thanks, but one of my MacBook that is also experiencing the problem is much further :slight_smile:


Defiantly i have more non happy “rotten apple” users in my hotspot,
most have random disconnecting all, just as your log messages.
Other brands don’t have such problems.
I even don’t use wifi encryption
my advice install bootcamp or linux

Thanks but this is more a political stance against the brand.

I only ask for a solution. I am sure Mikrotik wants to support the user base of Apple too.

And don’t get me wrong, I don’t hate Windows nor Linux :slight_smile:

Ok i think I found the solution.


I suspect the following :


First of all, in order not to accept “illegal” clients on my network, I have followed this wiki : http://wiki.mikrotik.com/wiki/How_to_block_non_DHCP_clients_without_the_firewall

How to block non DHCP clients without the firewall
Set add-arp to yes on the DHCP server instance. See the manual for details.

Set the interface ARP mode to reply-only. See the manual for details.

At that point the router won’t ARP for DHCP clients, so it can’t talk to them on layer 2 and they won’t receive any packets from the router. DHCP clients, however, will be added to the ARP table by the DHCP server and will work as usual.

This can be combined with static DHCP leases - simply set the pool to static-only and add manual IP to MAC mappings under DHCP server leases.

On the other hand, as I am busy setting up my network, and might change dynamic IP addresses of my different computers quite often until everything is ok, I am using a DHCP Lease Time of 3 minutes (!).

Now, I have extended the Lease time to 1 day, and the problem seems solved now. No more link break.

So I assume that during a short time when DHCP reassignes the dynamic address every 3 minutes, for a very short time the router won’t ARP for DHCP clients, and so it can’t talk to them on layer 2 and they won’t receive any packets from the router. Hence the very short link break.

The solution is to increase significantly the Lease time, but I still believe this is a bug and Mikrotik should try to replicate this in order to solve the problem. A DHCP lease time of 3 minutes, is very short indeed, but is valid and should not create a problem like this.

What clients ??? - your router is in your bedroom ???

those ping are horrible. Are you sure you dont have a wireless tv sender in the house or similar wireless device using the 2.4ghz spectrum

These pings have been recorded while downloading a big file, just to provoke the problem. Hence some ping delays.