Path error message trigger

[wirzli]

Hi

I made a network with two different paths to a destination. Now the source sends permanent a ping to the destination. In this communication a mesh point breaks down. It takes more than 10 seconds to send a route error and find a new path to the destination. Is this normal or is it possible to send the path error message more immediately.

I set the mesh_hwmp_active_path_timeout parameter to 30000 TU.

Best Regards

[chunyeow]

dot11MeshHWMPactivePathTimeout is currently default to 5000 TU (1 TU = 1024
microseconds). So it is 5 seconds.

Since you have enlarge the value, so your path will then remain active for
longer time than the default one. If you want to do quick path recovery,
suggest that you reduce the dot11MeshHWMPactivePathTimeout.

---

Chun-Yeow

On Tue, Nov 22, 2016 at 8:24 PM, Scaramanga07 [email protected]
wrote:

Hi

I made a network with two different paths to a destination. Now the source
sends permanent a ping to the destination. In this communication a mesh
point breaks down. It takes more than 10 seconds to send a route error and
find a new path to the destination. Is this normal or is it possible to
send the path error message more immediately.

I set the mesh_hwmp_active_path_timeout parameter to 30000 TU.

Best Regards

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#52, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBewuOuhpt9nyfb8OeOrHUci9Bp8uEJks5rAt7vgaJpZM4K5WKk
.

[wirzli]

Many thanks for your answer.

I set the mesh_hwmp_active_path_timeout parameter to 30000 TU because I thougt, that I could see the path error message.
Do you know when the path error message is generated and is the mesh_hwmp_active_path_timeout parameter the only way for a quick path recovery?

I have a high dynamic mesh network and the path error should be send immediately when the links break down.

Best Regards

[chunyeow]

You can probably take a look on the ieee80211s_update_metric whereby
mesh_plink_broken is called when the number of transmitted frame is not ACK
and exceeding certain threshold.

---

Chun-Yeow

On Wed, Nov 23, 2016 at 12:15 AM, Scaramanga07 [email protected]
wrote:

Many thanks for your answer.

I set the mesh_hwmp_active_path_timeout parameter to 30000 TU because I
thougt, that I could see the path error message.
Do you know when the path error message is generated and is the
mesh_hwmp_active_path_timeout parameter the only way for a quick path
recovery?

I have a high dynamic mesh network and the path error should be send
immediately when the links break down.

Best Regards

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#52 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBewlVEIfw5Fy8ddppAaheHNRJkAU7Cks5rAxUQgaJpZM4K5WKk
.

[wirzli]

Hi Chun-Yeow

Thank you for your answer. Sorry that I have not written to you earlier.

I've tested the Error Trigger now with a link breakdown during a UDP Datastream (SIP Connection) and the PERR was generated immediatly (0.3s) after the threshold of not ACK Packages was reached.
I think the problem was that Ping (ICMP) has not generated enough traffic to reach the threshold.

The source code contains the value 95 for the threshold. Do you now how this value comes about? Is this the amount of not ACK packets or is it something like a percentage of not ACK packets?

Best regards

[chunyeow]

sta->mesh->fail_avg is kind of exponentially weighted moving average of the average failed transmission. The threshold value is required to ensure enough number of failed transmission (unicast frame not ACKed by peer mesh STA) before declaring the mesh plink is broken. It is more like percentage.

…

On Fri, Dec 2, 2016 at 4:34 AM, Scaramanga07 ***@***.***> wrote: Hi Chun-Yeow Thank you for your answer. Sorry that I have not written to you earlier. I've tested the Error Trigger now with a link breakdown during a UDP Datastream (SIP Connection) and the PERR was generated immediatly (0.3s) after the threshold of not ACK Packages was reached. I think the problem was that Ping (ICMP) has not generated enough traffic to reach the threshold. The source code contains the value 95 for the threshold. Do you now how this value comes about? Is this the amount of not ACK packets or is it something like a percentage of not ACK packets? Best regards, — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewleNVD_TQ9MSTSF9Mbj3JPvRfw_mks5rDy9vgaJpZM4K5WKk> .