On Thu, Jun 11, 2015 at 3:56 PM, Lukas Göstl <[email protected]> wrote: > First of all, thanks for your help! > > Yeoh, the patch for ath9k_htc was already applied. > > I have added some Debug messages in mac80211 and logged the output of mpath > dump for the specific path. > More exactly I logged the metrics in function "hwmp_route_info_get" because > of this statement: > if (SN_GT(mpath->sn, orig_sn) || > (mpath->sn == orig_sn && > new_metric >= mpath->metric)) > { > > In my log I can see that sometimes the orig_sn is greater than mpath->sn and > the path is taken over while the metric is bad. > > Details to the mesh network: > Node A -> Node B > bc:30:7d:97:9e:24 -60 dBm bc:30:7d:97:9c:33 > > To simulate traffic between these nodes I use iperf. > > Log of mpath dump on Node A, when the path changes: > 08-55-11 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 927 127 0 1676 > 100 0 0x5 > 08-55-12 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 4403 > 100 0 0x15 > 08-55-13 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 3136 > 100 0 0x15 > 08-55-14 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 1934 > 100 0 0x15 > 08-55-16 > bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 4747 > 100 0 0x5 > 08-55-17 > bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 3455 > 100 0 0x5 > 08-55-18 > bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 2265 > 100 0 0x5 > 08-55-19 > bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 1070 > 100 0 0x5 > 08-55-21 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 3834 > 100 0 0x15 > 08-55-22 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 2580 > 100 0 0x15 > 08-55-23 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 1391 > 100 0 0x15 > 08-55-24 > bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 931 114 0 4117 > 100 0 0x5 > > Output of the metrics (from new to old): > Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG: > new metric1 for bc:30:7d:97:9c:33: 114 > Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG: > mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:9c:33 > Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG: > metrics #1 of bc:30:7d:97:9c:33: mpath->sn 929 | orig_sn 930 | orig_metric 0 > | last_hop_metric 114 | new_metric 114 | old_mpath->metric 241 > Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: > received PREP from bc:30:7d:97:9c:33 | metric: 241 > Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG: > new metric1 for bc:30:7d:97:9c:33: 241 > Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG: > mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:9e:22 > Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG: > metrics #1 of bc:30:7d:97:9c:33: mpath->sn 929 | orig_sn 929 | orig_metric > 127 | last_hop_metric 114 | new_metric 241 | old_mpath->metric 600 > Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: > received PREP from bc:30:7d:97:9c:33 | metric: 600 > Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG: > new metric1 for bc:30:7d:97:9c:33: 600 > Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG: > mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:91:12 > Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG: > metrics #1 of bc:30:7d:97:9c:33: mpath->sn 928 | orig_sn 929 | orig_metric > 316 | last_hop_metric 284 | new_metric 600 | old_mpath->metric 114 > Jun 11 08:55:11 debug kern kernel: [166554.372000] wlan0: LG: > fresh_info = false | mpath->sn 928 | orig_sn 928 | new_metric 983 | > old_mpath->metric 114 > Jun 11 08:55:11 debug kern kernel: [166554.372000] wlan0: LG: > metrics #1 of bc:30:7d:97:9c:33: mpath->sn 928 | orig_sn 928 | orig_metric > 459 | last_hop_metric 524 | new_metric 983 | old_mpath->metric 114
Based on your kernel log, it seems that you have not received PREP from bc:30:7d:97:9c:33 directly (single hop) for SN 929, only from both bc:30:7d:97:91:12 and bc:30:7d:97:9e:22. bc:30:7d:97:9e:22 is having better metric, so it is chosen. Maybe you can confirm whether path selection frame (PREP directly from bc:30:7d:97:9c:33) got lost by doing packet capturing over the air as pointed out by Bob. --- Chun-Yeow _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
