[B.A.T.M.A.N.] translation of batman-adv

[B.A.T.M.A.N.] translation of batman-adv

[唐鼎]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

hi!
Dose the translation of batman-adv support fast roaming between batman nodes(every batman node has two wireless interface under a bridge,one works in ap mode,another works in adhoc mode for batman' routing)

[-- Attachment #2: Type: text/html, Size: 626 bytes --]

[B.A.T.M.A.N.] terra-net (Mesh im Handy)

[thomasasta]

Hallo, vielleicht bekommt man Batman auch in Openmoko Linux Handy?

http://www.openmoko.org/

Dann hätte man eine Alternative zum Terra-Net, was bestimmt closed source ist.

Danke Gruss

P2P-Mobilfunksystem ermöglicht Gratis-Anrufe
Quelle: http://www.openmoko.org/

"Mesh-Netzwerk mit Handys bedeutet das Ende von GSM-Netzen" -
Technologie ist im WLAN-Bereich ein Hoffnungsträger
Das schwedische Unternehmen TerraNet hat eine Möglichkeit entwickelt,
mobile Kommunikation ohne ein herkömmliches Mobilfunknetzwerk
umzusetzen. Die Handys werden dabei in ein Peer-to-Peer-System
eingebunden und vernetzen sich untereinander, berichtet BBC online.
Der Grundgedanke ist ein sogenanntes Mesh-Netzwerk, eine
dezentralisierte Infrastruktur, bei der jeder Knoten - in diesem Fall
sind es die Mobiltelefone - nur soviel Leistung bringen muss, um sich
mit dem nächsten zu verbinden. Der größte Vorteil der Technologie ist,
dass Gespräche durch die Umgehung eines Providers kostenlos geführt
werden können.

Mesh-Technologie ist derzeit vor allem im WLAN-Bereich ein
Hoffnungsträger. Mesh-fähige Geräte senden und empfangen Daten.
Gleichzeitig nehmen sie Router-Funktionen wahr und leiten Daten an
andere Clients weiter. Die Ingenieure wollen damit Funklöcher stopfen.
Dieselbe Intention verfolgte Anders Carlius, der Gründer von TerraNet.
Durch die Anwendung der Mesh-Technologie bei Mobiltelefonen, soll es
selbst in Gebieten mit schwacher Mobilfunkversorgung möglich sein,
Telefonate zu führen. Ein Anruf wird dabei solange von Telefon zu
Telefon weitergeleitet, bis er das Zielgerät erreicht.

Projekte in Tansania und Equador

Carlius arbeitet seit 2002 an der Idee und konnte erste Projekte
kürzlich in Tansania und Equador starten. Das System ist derzeit vor
allem für Gebiete gedacht, in denen die Aufstellung von Basisstationen
entweder nicht möglich oder schlicht unrentabel ist - beispielsweise
in Wüstengebieten. "In manchen Gegenden in Afrika, Südamerika, Indien
oder China können wir die Ersten sein, die den Menschen die
Möglichkeit zur Kommunikation geben. Darüber hinaus gibt es noch eine
Vielzahl an Möglichkeiten, unsere Technologie anzuwenden", meint
Carlius gegenüber pressetext.

Sobald ein TerraNet-Gerät eingeschaltet wird, sucht es seine Umgebung
im Umkreis von etwa einem Kilometer nach weiteren Geräten ab und
verbindet sich mit ihnen. Somit wird das Netz mit jedem weiteren Gerät
erweitert und die Abdeckung durch das Netz vergrößert. Ein Anruf in
ein anderes, nicht direkt verbundenes Handy-Netzwerk soll über VoIP
funktionieren. Dazu müsste lediglich ein Gerät pro Netzwerk mit dem
Internet verbunden sein. Befindet sich das Zielhandy also nicht im
eigenen Netz, wird der Anruf über das Web zum entsprechenden Mesh-Netz
weitergeleitet.

Nur mit speziellen Handys

Derzeit funktioniert das TerraNet-System nur mit speziellen
Mobiltelefonen. Allerdings hofft Carlius, dass die Technologie künftig
ähnlich wie Bluetooth als zusätzliche Funktion in handelsübliche
Handys integriert wird. Weniger angetan von der TerraNet-Idee sind
laut Carlius die großen Mobilfunkprovider. Der TerraNet-Gründer
liefert zugleich die Begründung: "Peer-to-Peer-Kommunikation im
Mobilfunk könnte möglicherweise das Ende der GSM-Netze bedeuten." Die
Technologie sei nicht ausgereift und funktioniere nicht, lauten die
Gegenargumente, die Carlius jedoch nicht gelten lässt. Er verweist auf
den Telefonhersteller Ericsson, der bereits drei Mio. Pfund (4,4 Mio.
Euro) in TerraNet investiert habe.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: [B.A.T.M.A.N.] translation of batman-adv

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hey,

i tested this today (and fixed a 2 bugs regarding this ;), and that
works. I used the same setup as you described, and when reassociating it
kept pinging ... :)
The host-announcements for the bridging are sent with the
batman-packets, and it takes 1 second maximum for the ap node to make
the first announcement when it got a new host. (But probably a little longer until
the whole mesh-network knows).
If you want to use this please use the batman-saxnet branch of
batman-advanced for now until its merged back into the trunk.

Best Regards,
        Simon

On Thu, Sep 13, 2007 at 02:08:30PM +0800, 唐鼎 wrote:
> hi!
> Dose the translation of batman-adv support fast roaming between batman nodes(every batman node has two wireless interface under a bridge,one works in ap mode,another works in adhoc mode for batman' routing)

> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] translation of batman-adv

[唐鼎]

hi!
but 1 second delay is too long to some real-time applications.
i have look insight the batman-adv code. 
caching source host's mac and originater's mac when batman node  forwards a packet  maybe is better way
----- Original Message ----- 
From: "Simon Wunderlich" <simon.wunderlich@s2003.tu-chemnitz.de>
To: "The list for a Better Approach To Mobile Ad-hoc Networking" <b.a.t.m.a.n@open-mesh.net>
Sent: Friday, September 14, 2007 2:46 PM
Subject: Re: [B.A.T.M.A.N.] translation of batman-adv


> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

Re: [B.A.T.M.A.N.] translation of batman-adv

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

Hey,

Yes we thought about that too (actually that was my first idea), 
but this might lead to inconsitency as not all hosts will get an update
when a node moves but only those nodes which are on the way. Furthermore
the packet reading (and cache updating) increases latency to forwarding. 
A solution might be to increase the rate in which batman-packets are
sent (because then host announcement goes with them), or create a new
packet type for announcement and send these more often. Both brings us
much more noise in the mesh.
I wonder if having a wifi-mesh is good for (hard?) real-time
applications. Even reassociating to a new access point might take a few
seconds (scanning & finding), or there is packet loss if you get out of 
the range from the previous ap until your wifi card changes to another
AP.

Regards
	Simon



On Fri, Sep 14, 2007 at 03:11:35PM +0800, 唐鼎 wrote:
> hi!
> but 1 second delay is too long to some real-time applications.
> i have look insight the batman-adv code. 
> caching source host's mac and originater's mac when batman node  forwards a packet  maybe is better way

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] translation of batman-adv

[??]

hi
i have a question:
when a node moved from one ap to another ap, will the two aps  announce this node
until the "previous node" age out? 
----- Original Message ----- 
From: "Simon Wunderlich" <simon.wunderlich@s2003.tu-chemnitz.de>
To: "The list for a Better Approach To Mobile Ad-hoc Networking" <b.a.t.m.a.n@open-mesh.net>
Sent: Friday, September 14, 2007 4:03 PM
Subject: Re: [B.A.T.M.A.N.] translation of batman-adv


> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[B.A.T.M.A.N.] a proposal

[a.anselmi]

A client node take its decision about chosing a gateway in a unilateral
way, that is chosing gateway on a ranking basis (or wathever else)
checking the path "node-->gateway" or "node-->hop-->gateway" (also if the
second is not always preferred, chosing a poor link "node-->gateway"
rather then best links "node-->hop-->gateway").

Presuming the node has a bouquet of canditate gateways: we can think to
use an udp packet polling the candidate gateways and asking them "how you
see me?" so the the node itself can obtain a path evaluation computed at
gateway side and not only at node side.
For example
presuming node A can chose among gateways G1 and G2 (the candidate
gateways) it will make its choice upon path evaluation:

A --> hops --> G1
A --> hops --> G1
where [hops] can be also 0 (no hops between A and Gn)

and computing OGMs coming from neighboors.

Well, node A can send two udp packet (same format as OGM but different
op-code in payload||different dest port) to G1 and G2 asking to send their
path evaluation like "G1 --> hops --> A" evaluation (received from
candidate G1) and "G2 --> hops --> A" evaluation (received from candidate
G2). In this way node A has a more clear vision about the entire path A
<--> G_candidate and can take a more serious decision.

Using udp requests we introduce low latency than tcp and with a separate
thread on gateway (with a poor resources consumpion) we can manage this
task without effetcing the main.

What are you thoughts about?

--
Antonio

Re: [B.A.T.M.A.N.] a proposal

[elektra]

Hi Antonio -

your suggestion sounds reasonable and is worth thinking about. However I think 
this issue will become less important with B.A.T.M.A.N.-IV since it will 
massively improve the routing metric. I think it is fair enough that a 
gateway client will unilaterally choose the gateway - the number of OGMs 
received should provide enough information for the client to choose the right 
gateway. 

cu elektra


> A client node take its decision about chosing a gateway in a unilateral
> way, that is chosing gateway on a ranking basis (or wathever else)
> checking the path "node-->gateway" or "node-->hop-->gateway" (also if the
> second is not always preferred, chosing a poor link "node-->gateway"
> rather then best links "node-->hop-->gateway").
>
> Presuming the node has a bouquet of canditate gateways: we can think to
> use an udp packet polling the candidate gateways and asking them "how you
> see me?" so the the node itself can obtain a path evaluation computed at
> gateway side and not only at node side.
> For example
> presuming node A can chose among gateways G1 and G2 (the candidate
> gateways) it will make its choice upon path evaluation:
>
> A --> hops --> G1
> A --> hops --> G1
> where [hops] can be also 0 (no hops between A and Gn)
>
> and computing OGMs coming from neighboors.
>
> Well, node A can send two udp packet (same format as OGM but different
> op-code in payload||different dest port) to G1 and G2 asking to send their
> path evaluation like "G1 --> hops --> A" evaluation (received from
> candidate G1) and "G2 --> hops --> A" evaluation (received from candidate
> G2). In this way node A has a more clear vision about the entire path A
> <--> G_candidate and can take a more serious decision.
>
> Using udp requests we introduce low latency than tcp and with a separate
> thread on gateway (with a poor resources consumpion) we can manage this
> task without effetcing the main.
>
> What are you thoughts about?
>
> --
> Antonio
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] translation of batman-adv

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

No, 

the batman-adv currently has a timeout for client-macs of 5 minutes. But
as soon as another new ap announce the mac as his node, the old ap will
recognize this, update his table (remove the client-mac) and stop announcing it. 
So only the new ap will keep on announcing, not both.

Regards,
	Simon


On Fri, Sep 14, 2007 at 06:30:11PM +0800, ?? wrote:
> hi
> i have a question:
> when a node moved from one ap to another ap, will the two aps  announce this node
> until the "previous node" age out? 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]