Hi, Cedric

I believe that the ARP request/reply is used to enable the mesh gate
to register the mesh STA outside the MBSS. So if you static assign the
MAC address to a specific IP address, I don't think that it will ever
work.

---
Chun-Yeow

On Tue, Feb 12, 2013 at 5:58 PM, voncken <[email protected]> wrote:
> My test platform is:
>
> LAPTOP_A ------------ MeshGate1 ----------------- MeshGate2 ---------------
> LAPTOP_B
>                    LAN (DS)                  WiFi (MBSS)
> LAN (DS)
> 08:00:27:c1:bf:06   00:09:90:00:2b:f2              00:09:90:00:2d:ee
> b8:88:e3:9e:fb:5e
>
> In each laptop, I set a static entry in the ARP table to the other laptop.
>
> I turn on both meshgates and I try to ping LAPTOP_B from LAPTOP_A.
> Often the ping has no response.
> If Ping gets a response, I reboot the MeshGate1. After this reboot ping
> never gets a response again.
>
> If I look with wireshark the Wireless traffic at this time, The MeshGate1
> sends PREQ repeatedly with a target STA Address of b8:88:e3:9e:fb:5e
> (LAPTOP_B Mac address).
> It's normal, because the meshgate1 does no know if this device is inside or
> outside the MBSS (thanks to Yeoh to explain this point).
>
> But the MeshGate1 stays in this state indefinitely (I waited several
> minutes).
> The ICMP frames are never sent to the MeshGate in this default settings
> (given below).
>
> While I don't stop the ping, In the MeshGate1 I can see these mpath :
> DEST ADDR         NEXT HOP          IFACE       SN      METRIC  QLEN
> EXPTIME DTIM    DRET    FLAGS
> 90:a4:de:aa:40:a8 90:a4:de:aa:40:a8 wlan0       0       1366    0       4832
> 0       0       0x11
> 90:a4:de:21:4e:f7 90:a4:de:21:4e:f7 wlan0       0       1366    0       4832
> 0       0       0x11
> b8:88:e3:9e:fb:5e 00:00:00:00:00:00 wlan0       0       0       2       0
> 1600    4       0x2
>
> If I delete the Mpath b8:88:e3:9e:fb:5e, the ICMP frames are sent to
> MeshGate2, without any other management frame.
>
> ====== default Mesh settings =========
> mesh_retry_timeout = 100 milliseconds
> mesh_confirm_timeout = 100 milliseconds
> mesh_holding_timeout = 100 milliseconds
> mesh_max_peer_links = 32
> mesh_max_retries = 3
> mesh_ttl = 31
> mesh_element_ttl = 31
> mesh_auto_open_plinks = 1
> mesh_hwmp_max_preq_retries = 4
> mesh_path_refresh_time = 1000 milliseconds
> mesh_min_discovery_timeout = 100 milliseconds
> mesh_hwmp_active_path_timeout = 5000 TUs
> mesh_hwmp_preq_min_interval = 10 TUs
> mesh_hwmp_net_diameter_traversal_time = 50 TUs
> mesh_hwmp_rootmode = 0
> mesh_hwmp_rann_interval = 5000 TUs
> mesh_gate_announcements = 0
> mesh_fwding = 1
> mesh_sync_offset_max_neighor = 50
> mesh_rssi_threshold = 0 dBm
> mesh_hwmp_active_path_to_root_timeout = 6000 TUs
> mesh_hwmp_root_interval = 5000 TUs
> mesh_hwmp_confirmation_interval = 2000 TUs
>
> ======== other tests =========
> I try with mesh_gate_announcements=1 and mesh_hwmp_rootmode=1, I have the
> same issue.
> I try with mesh_gate_announcements=1 and mesh_hwmp_rootmode=3 or 4, ICMP
> bursts are sent each preceded by DRET (Discovery retries) PREQ's, resulting
> in the ping being very slow.
>
> If you need more information, do not hesitate to contact me.
>
> Regards.
>
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel

Reply via email to