public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: cmsv <cmsv@wirelesspt.net>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: [B.A.T.M.A.N.] Classes and purposed classes (problem to solve)
Date: Fri, 15 Feb 2013 10:35:17 -0500	[thread overview]
Message-ID: <511E55B5.60900@wirelesspt.net> (raw)

Scenario:
I have recently moved 13 nodes previously using wds  to batman-adv.
One problem that i am encountering is the gateway selection and its
actually defectiveness.
This problem has be seen when the client nodes are set on class 20.

The node clients in fact select the gateways that advertise better link
quality usually above 200 but at the same time some clients  end up
connecting to a gateway that is either too slow or unusable either due
to routing or other factors such as distance and even clear visibility.
In one case the node connects to something that defies logic.

I thought about ways to work around this and came up with an idea that
may help which means the creation of 2 new classes.

- Preferred gateway fall-back

- Preferred fixed gateway

For  Preferred gateway fall-back:

consider the gateway's advertised quality towards the gateway and stick
with the selection until the gateway disappears returning to it soon as
it returns regardless of any other data.

- Preferred fixed gateway
Manual gateway selection by the node owner or admin. (wds type)

If these classes cannot be created; maybe a plugin of some sort could
be. could be called "gordon".


 I understand that this idea may sound useless the same way blocking
originators may be for someone but in some scenarios just like blocking
originators it look to me very valid.
My current problem is that the link quality seems to go up and down like
 a roller coaster in a specific order which causes the clients to switch
constantly sometimes many times per hour.
While this does not seem to be an issue for most client nodes; for 2 of
them it means no internet access at all.

The solution for now seems to be having these 2 nodes forced to use 1
specific gateway.


I am quite open to any ideas that may help resolve this issue that has
been casing some "uninformed people" to become headaches.





-- 






Redes wireless
http://wirelesspt.net

             reply	other threads:[~2013-02-15 15:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 15:35 cmsv [this message]
2015-11-14 18:04 ` [B.A.T.M.A.N.] Classes and purposed classes (problem to solve) 3zl Trizonelabs
2015-11-16  2:13   ` Marek Lindner
  -- strict thread matches above, loose matches on Subject: below --
2015-11-16 21:00 3zl Trizonelabs
2015-11-17  1:15 ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=511E55B5.60900@wirelesspt.net \
    --to=cmsv@wirelesspt.net \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox