In addition to what Thomas's suggestion, do you mind to share the
/etc/config/network and /etc/config/wireless for all the mesh nodes
and gateway?
By the way, MR3020 has no internet access, am I right? Only TP-Link
740n offers Internet access, am I right? If both offering Internet
access, do you turn STP on while bridging?
---
Chun-Yeow
On Sat, Apr 12, 2014 at 5:02 PM, Constantin Sandu <csand...@lycos.com> wrote:
> I ran some more tests.
>
> Moved MR3020 in the same room with the gateway. As expected, no more packets
> lost between gateway and MR3020.
> But I had 50% loss from gateway to the other mesh node.
> When I unplugged MR3020, losses went down to 2%.
>
> With all 3 routers in the same room there are no losses in the mesh.
>
>
> Apr 12, 2014 02:50:50 AM, devel@lists.open80211s.org wrote:
>
>>After enabling mesh gate announcements on the gateway:
>>
> >From MR3020:
>>root@OpenWrt:~# ping 10.0.1.1
>>PING 10.0.1.1 (10.0.1.1): 56 data bytes
>>64 bytes from 10.0.1.1: seq=0 ttl=64 time=10.870 ms
>>64 bytes from 10.0.1.1: seq=0 ttl=64 time=12.818 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=1 ttl=64 time=3.599 ms
>>64 bytes from 10.0.1.1: seq=1 ttl=64 time=8.467 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=2 ttl=64 time=2.517 ms
>>64 bytes from 10.0.1.1: seq=2 ttl=64 time=2.697 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=3 ttl=64 time=12.643 ms
>>64 bytes from 10.0.1.1: seq=3 ttl=64 time=13.693 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=4 ttl=64 time=3.296 ms
>>64 bytes from 10.0.1.1: seq=5 ttl=64 time=110.710 ms
>>64 bytes from 10.0.1.1: seq=5 ttl=64 time=110.854 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=6 ttl=64 time=10.489 ms
>>64 bytes from 10.0.1.1: seq=6 ttl=64 time=11.985 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=7 ttl=64 time=4.096 ms
>>64 bytes from 10.0.1.1: seq=7 ttl=64 time=4.261 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=8 ttl=64 time=9.442 ms
>>64 bytes from 10.0.1.1: seq=8 ttl=64 time=12.430 ms (DUP!)
>>64 bytes from 10.0.1.1: seq=9 ttl=64 time=6.262 ms
>>64 bytes from 10.0.1.1: seq=10 ttl=64 time=2.463 ms
>>64 bytes from 10.0.1.1: seq=13 ttl=64 time=116.767 ms
>>64 bytes from 10.0.1.1: seq=14 ttl=64 time=2.425 ms
>>64 bytes from 10.0.1.1: seq=15 ttl=64 time=1.702 ms
>>64 bytes from 10.0.1.1: seq=16 ttl=64 time=3.112 ms
>>64 bytes from 10.0.1.1: seq=17 ttl=64 time=1.974 ms
>>64 bytes from 10.0.1.1: seq=18 ttl=64 time=7.320 ms
>>64 bytes from 10.0.1.1: seq=19 ttl=64 time=4.921 ms
>>64 bytes from 10.0.1.1: seq=20 ttl=64 time=2.658 ms
>>^C
>>--- 10.0.1.1 ping statistics ---
>>113 packets transmitted, 19 packets received, 8 duplicates, 83% packet loss
>>round-trip min/avg/max = 1.702/18.313/116.767 ms
>>
>>So, after receiving some duplicates, after 20 replies it stopped receiving
>>them back, although tcpdump on the gateway showed it receives all echo
>>requests and replies to them.
>>
>>Here's how mpath dump on MR3020 looks like now (just a few seconds between
>>the commands):
>>
>>root@OpenWrt:~# iw dev mesh_g mpath dump
>>DEST ADDR NEXT HOP IFACE SN METRIC QLEN
>>EXPTIMEDTIM DRET FLAGS
>>00:ca:ff:ee:00:13 00:ca:ff:ee:00:13 mesh_g 1638 1261 0 1220
>> 00 0x15
>>00:ca:ff:ee:00:11 00:ca:ff:ee:00:11 mesh_g 5768 203 0 1230
>> 100 0 0x15
>>root@OpenWrt:~# iw dev mesh_g mpath dump
>>DEST ADDR NEXT HOP IFACE SN METRIC QLEN
>>EXPTIMEDTIM DRET FLAGS
>>00:ca:ff:ee:00:13 00:ca:ff:ee:00:13 mesh_g 1650 1261 0 0
>> 00 0x14
>>00:ca:ff:ee:00:11 00:ca:ff:ee:00:11 mesh_g 5795 203 0 4330
>> 200 1 0x5
>>root@OpenWrt:~# iw dev mesh_g mpath dump
>>DEST ADDR NEXT HOP IFACE SN METRIC QLEN
>>EXPTIMEDTIM DRET FLAGS
>>00:ca:ff:ee:00:13 00:ca:ff:ee:00:13 mesh_g 1653 1261 0 2250
>> 00 0x15
>>00:ca:ff:ee:00:11 00:ca:ff:ee:00:11 mesh_g 5798 203 0 2260
>> 100 0 0x15
>>root@OpenWrt:~#
>>
>>
>>Thanks,
>>Constantin
>>
>>Apr 11, 2014 05:44:45 PM, devel@lists.open80211s.org wrote:
>>>On Fri, Apr 11, 2014 at 12:00 PM, Constantin Sandu csand...@lycos.com> wrote:
>>>> Wow, lots of information to think about, I'm glad I came here in the first
>>>> place :)
>>>>
>>>> I'll try to answer to the questions the best I can, I just hope I
>>>> understood them well
>>>>
>>>>>- Is "gateway" a root mesh node?
>>>> No, it does not advertise itself as a gateway, it is a gateway because the
>>>> other mesh nodes have default routes to this mesh node
>>>
>>>An IP gateway then? How is the behavior if you enable mesh gate
>>>announcements? (iw mesh_g set mesh_param mesh_gate_announcements=1).
>>>This will cause the gateway node to generate frames which allow the
>>>other nodes to always maintain a path back to the gateway
>>>(ostensibly).
>>>
>>>>>- How are pings from :12 to :13?
>>>> Right now about 11% loss (but I've seen worse)
>>>>
>>>>>- Are you sure pings from :13 to :11 experience a lot of loss?
>>>> Right now, yes, 20%, see bellow the pause between 31 and 37
>>>> 64 bytes from 10.0.1.3: seq=27 ttl=64 time=4.454 ms
>>>> 64 bytes from 10.0.1.3: seq=28 ttl=64 time=3.049 ms
>>>> 64 bytes from 10.0.1.3: seq=29 ttl=64 time=3.614 ms
>>>> 64 bytes from 10.0.1.3: seq=30 ttl=64 time=2.320 ms
>>>> 64 bytes from 10.0.1.3: seq=31 ttl=64 time=11.109 ms
>>>> 64 bytes from 10.0.1.3: seq=37 ttl=64 time=7.159 ms
>>>> 64 bytes from 10.0.1.3: seq=38 ttl=64 time=7.715 ms
>>>>
>>>>>- How is mpath stability while pinging?
>>>> I am not sure how to evaluate it, but issueing "iw dev mesh_g mpath dump"
>>>> while pinging, it seems to be stable, at least regarding next hops - right
>>>> now gateway has direct path to each of the mesh nodes, while one of the
>>>> mesh nodes (MR3020, :12) has path to gateway (:11) through the other mesh
>>>> node. (But I've seen them having direct path to each other before)
>>>>
>>>> Gateway:
>>>> root@OpenWrt:~# iw dev mesh_g mpath dump
>>>> DEST ADDR NEXT HOP IFACE SN METRIC QLEN
>>>> EXPTIMEDTIM DRET FLAGS
>>>> 00:ca:ff:ee:00:13 00:ca:ff:ee:00:13 mesh_g 1180 211 0
>>>> 3620 100 0 0x15
>>>> 00:ca:ff:ee:00:12 00:ca:ff:ee:00:12 mesh_g 1972 190 0
>>>> 3620 100 0 0x5
>>>
>>>Hmm. For some reason the gateway has not set the RESOLVED flag (0x10)
>>>for the path toward :12...
>>>
>>>That flag combination seems to only happen in the following branch in
>>>net/mac80211/mesh_hwmp.c (mesh_path_timer()):
>>>
>>> if (mpath->flags & MESH_PATH_RESOLVED ||
>>> (!(mpath->flags & MESH_PATH_RESOLVING))) {
>>> mpath->flags &= ~(MESH_PATH_RESOLVING | MESH_PATH_RESOLVED);
>>> spin_unlock_bh(&mpath->state_lock);
>>> }
>>>
>>>huh? I wonder what the purpose behind that check for !RESOLVING was
>>>(added in 5ee68e5b: mac80211: mesh gate implementation). It looks like
>>>the mesh_path_timer is only set after queuing a PREQ.
>>>
>>>This is also the case in one of your earlier mpath dumps (from :13):
>>>
>>>00:ca:ff:ee:00:11 00:ca:ff:ee:00:11 mesh_g 1739 421 0
>>> 2200 200 1 0x5
>>>
>>>> MR3020:
>>>> root@OpenWrt:~# iw dev mesh_g mpath dump
>>>> DEST ADDR NEXT HOP IFACE SN METRIC QLEN
>>>> EXPTIMEDTIM DRET FLAGS
>>>> 00:ca:ff:ee:00:13 00:ca:ff:ee:00:13 mesh_g 1180 102 0
>>>> 1960 100 0 0x15
>>>> 00:ca:ff:ee:00:11 00:ca:ff:ee:00:13 mesh_g 3705 254 0
>>>> 1960 100 0 0x15
>>>>
>>>>>Looks like all mpaths went through at least 1000 generations, while
>>>>>paths toward :12 only went through about 100?. The topology makes
>>>>>sense if :12 is the mr3020 (shortest range, so he needs to go through
>>>>>:13 toward the gateway).
>>>>
>>>> I guess this is because the gateway and one of the mesh nodes stayed up
>>>> all night, while the little one (MR3020) I started today when I came home.
>>>> Each router is in a different room at my home.
>>>> You are perfectly right, :12 is indeed MR3020
>>>>
>>>>>Since killing one of the nodes improves performance so much, this
>>>>>could be a hidden node issue? Did you try enabling CTS/RTS?
>>>>
>>>> Do you mean something like this? root@OpenWrt:~# iw phy0 set rts 1000
>>>> I tried it on all routers but unfortunately it didn't make any difference.
>>>> Is there some other way?
>>>
>>>Not sure. This kind of looks like an mpath issue. Especially
>>>interesting you see all the ICMP frames on the gateway!
>>>
>>>Good luck.
>>>
>>>Thomas
>>>_______________________________________________
>>>Devel mailing list
>>>Devel@lists.open80211s.org
>>>http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
>>>
>>_______________________________________________
>>Devel mailing list
>>Devel@lists.open80211s.org
>>http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
>>
> _______________________________________________
> Devel mailing list
> Devel@lists.open80211s.org
> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@lists.open80211s.org
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
