o11s / open80211s

open80211s
Other
242 stars 55 forks source link

Path error message trigger #52

Open wirzli opened 7 years ago

wirzli commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/o11s/open80211s/issues/52, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewuOuhpt9nyfb8OeOrHUci9Bp8uEJks5rAt7vgaJpZM4K5WKk .

wirzli commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/o11s/open80211s/issues/52#issuecomment-262285672, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewlVEIfw5Fy8ddppAaheHNRJkAU7Cks5rAxUQgaJpZM4K5WKk .

wirzli commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/o11s/open80211s/issues/52#issuecomment-264287051, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewleNVD_TQ9MSTSF9Mbj3JPvRfw_mks5rDy9vgaJpZM4K5WKk .