4 Aug
2007
4 Aug
'07
9:38 p.m.
that should not be the case! You say even with the
stable connection
to your
near-by WRT that the HNA is added/deleted every 1 - 5
SECONDS ! And
even more
often at the distant WRT (so added/deleted every
SECOND ?).
Can you describe the setup and parametrization in more detail?
I have a Linux and two wrt's using rv495. the route is added and deleted
at same time as the message is printed.
linux: batmand -g 4 -a 141.56.0.0/16 wlan0
wrt-near: batmand -r 2 eth1
wrt-far: batmand -r 2 eth1
wrt-far: "-d3" add/del freq differs from 5 to 60 seconds
---------------
Gateway client - got IP (169.254.0.1) from gateway: 10.12.0.1
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Gateway client - releasing unused IP after timeout: 169.254.0.1
Adding default route via tun0 (table 67)
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Gateway client - got IP (169.254.0.1) from gateway: 10.12.0.1
Adding route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
Deleting route to 141.56.0.0/16 via 10.12.10.17 (table 65 - eth1)
root@10-1:~# ip rule;ip route list table bat_hna
0: from all lookup local
6599: from all to 141.56.0.0/16 lookup bat_hna
6600: from all to 10.0.0.0/8 lookup bat_route
6700: from all iif lo lookup bat_default
6701: from 127.0.0.0/8 lookup bat_default
6702: from 192.168.1.0/24 lookup bat_default
6703: from 192.168.178.0/24 lookup bat_default
6704: from 172.16.0.0/16 lookup bat_default
6705: from 172.16.0.0/16 lookup bat_default
10000: from all to 192.168.0.0/16 lookup main
10001: from all to 172.16.0.0/12 lookup main
10002: from all to 10.0.0.0/8 lookup main
10002: from all to 104.0.0.0/8 lookup main
10003: from all lookup gateway
32766: from all lookup main
32767: from all lookup default
141.56.0.0/16 via 10.12.10.17 dev eth1 proto static
root@10-1:~# ip rule;ip route list table bat_hna
0: from all lookup local
6600: from all to 10.0.0.0/8 lookup bat_route
6700: from all iif lo lookup bat_default
6701: from 127.0.0.0/8 lookup bat_default
6702: from 192.168.1.0/24 lookup bat_default
6703: from 192.168.178.0/24 lookup bat_default
6704: from 172.16.0.0/16 lookup bat_default
6705: from 172.16.0.0/16 lookup bat_default
10000: from all to 192.168.0.0/16 lookup main
10001: from all to 172.16.0.0/12 lookup main
10002: from all to 10.0.0.0/8 lookup main
10002: from all to 104.0.0.0/8 lookup main
10003: from all lookup gateway
32766: from all lookup main
32767: from all lookup default
root@10-1:~#
-----------------
Do you really think of a human-readable ascii string that you want to
flood
with an arbitrary length over the mesh with content
like: "Hello take
a cool
beer and see my fancy cool movie torrent-server at
105.10.bla.bub".
Iam not
against such communication but...
default OGM size: 10 bytes
OGM + HNA size: 15 bytes
OGM + example-TLV-ascii message: 95 bytes
... I am a bit scared about the amount of data which would be flooded
over the
mesh (at every originator interval) with no means for
stopping the
sources.
Therefore i asked if anybody knows a decent forman for describing such
services (preferably in a short and machine readable notation).
Perhaps another approach is to just have a kind of key-to-service list
(similar to /etc/services with a 16bit key) just roughly indicating
the type
of offered service together with another port/ip
where further
information
(of arbitrary length) about the indicated service can
be retrieved.
This would also allow to outsource part of the service-discovery to
another
daemon.
greetings,
axel
I have read the previous thread messages that talk about dns. I'm not
firm with this. But I think that the protocol offers a good way to
optimize flooding messages and avoids any loops. The network size is
defined by ttl of the OGMs and so it makes sence to use the knowledge
of this network size to send also other messages. any external process
does not know this and would over flood the network. If you are using a
passive way, where the nodes ask a server to retrieve such messages,
then in a decentralized network at least this server or serveral server
needs to be known. For this you will need such a message flooding
solution anyway.
The protocol should be flexible and provide such a feature no matter if
anyone uses it. Any how is providing a firmware with batmand, should
know what he is doing.
Cheers
Stephan