[B.A.T.M.A.N.] dynamic gateway / hna / services

[B.A.T.M.A.N.] dynamic gateway / hna / services

[Freifunk Dresden]

hi,

Question 1:

how does batmand detect whether the internet connection is really connected to
the internet or not. Or does batmand just relays on the -g parameter.
Until now we let run a cron job that checks for the real working  
gateway. Because we can not relay on the presence of the default  
route. User may use a different
router to connect to the internet and just add the default route this  
private router.
The problem is that the node offering a internet connection (-g)  
should also be able to access other internet connection if its local  
connection is brocken.

Question 2:

I'm currently checking how the HNA is working, but until now I can not  
see any HNA on a second node. Firewall is enabled completely for both  
nodes and each node sees the other nodes. I call batmand as follow:
Node1: batmand -t 63 -a 141.56.0.0/16 wlan0 bbs /t 2 bbc /t 2
Node2: batmand -t 63 eth1 bbs /t 2 bbc /t 2

But batmand -c -d 4 does not show any HNA messages and no HNA entry is  
stored in   routing table.

Beside of this the Idea to add/delete HNA without stopping batmand  
would be good. e.g. batmand -c -a <add-hna>
            batmand -c -A <del-hna>

Question 3:

If a node offers a ftp server (portforwarding) I like to offer this  
"service" via batmand like olsrd.
A generic solution would be good to just allow to send user text  
messages with the OGM.

e.g:sending:  batmand -c -m "this is my message" (called requlary by  
cron.d to send/update a message or command)
  the running batmand will need an addional options e.g. -m (script)  
that is called to process the incomming message.
e.g:  batmand -m process-message-script wlan0

The advantage would be, that each user that is using batman can offer  
different
services: e.g. populate a service list, news, software updates,....

Another Idea of the "-m" is to differenciate this parameter to -M <"message">
and -m <send-script>. by calling batmand -c -m send-script, batmand  
can setup stdin/stdou as binary file handle and fill a user-OGM with  
binary data that is then send.


Please tell me if some of the features already present in the  
batman-experimental trunk.

Kind regards
  Stephan

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Freifunk Dresden wrote:

> I'm currently checking how the HNA is working, but until now I can not
> see any HNA on a second node. Firewall is enabled completely for both
> nodes and each node sees the other nodes. I call batmand as follow:
> Node1: batmand -t 63 -a 141.56.0.0/16 wlan0 bbs /t 2 bbc /t 2
> Node2: batmand -t 63 eth1 bbs /t 2 bbc /t 2

> 
> But batmand -c -d 4 does not show any HNA messages and no HNA entry is
> stored in   routing table.

mmhh, the hna announcments are written into another routing table, have
you checked that ?

> If a node offers a ftp server (portforwarding) I like to offer this
> "service" via batmand like olsrd.
> A generic solution would be good to just allow to send user text
> messages with the OGM.

This is a bad idea in my opinion. A routing protocol has one purpose
which is routing, not flooding 99% useless information just because it
COULD.

i think the right approch for service discovery is using something like
dns for example. dns is very small overheaded, allows great redundancy,
works on demand...

using TXT and SRV records, a good dns infrastructure and user frontend,
it should be easy to publish services.

here in leipzig we already layed the ground stones for a widespanning,
redundant dns network using anycast ips for redundancy.

http://wiki.freifunk.net/FF-Zone

kindly regards
 Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpkZpy/mkIQp7AD0RAhrlAKCVDRFsf+6+909tsAxtCFM3oZSxugCfdKsT
sGLdwUFF9ckhxfLHikdfwP8=
=DW4D
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Daniel Poelzleithner schrieb:
> Freifunk Dresden wrote:
> 
>

<removed>

> 
> here in leipzig we already layed the ground stones for a widespanning,
> redundant dns network using anycast ips for redundancy.
> 
> http://wiki.freifunk.net/FF-Zone

thats less then i thought:
(Dieser Artikel enthält momentan keinen Text)

> 
> kindly regards
>  Daniel

greets, alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpzj8hx2RbV7T5aERAu9NAKDB2qSAowhx3fJwVsTaZV65zDWzDwCgjohw
1khAGF5OSII56igfv7+7nqg=
=dYpI
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[tetzlav]

Alexander Morlang schrieb:
> Daniel Poelzleithner schrieb:
> > here in leipzig we already layed the ground stones for a widespanning,
> > redundant dns network using anycast ips for redundancy.
>
> > http://wiki.freifunk.net/FF-Zone
>
> thats less then i thought:
> (Dieser Artikel enthält momentan keinen Text)

-> http://wiki.freifunk.net/FF-zone

;)

Regards
tetzlav

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Hi,

> This is a bad idea in my opinion. A routing protocol has one purpose
> which is routing, not flooding 99% useless information just because it
> COULD.
>
> i think the right approch for service discovery is using something like
> dns for example. dns is very small overheaded, allows great redundancy,
> works on demand...
>
> using TXT and SRV records, a good dns infrastructure and user frontend,
> it should be easy to publish services.

I totally agree to your point. Just because you can waste bandwidth with OLSR 
so easily there is no need for us to do the same.

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Morlang wrote:

>> http://wiki.freifunk.net/FF-Zone
> 
> thats less then i thought:
> (Dieser Artikel enthält momentan keinen Text)

;)

http://wiki.freifunk.net/FF-zone


greetings
 daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp2avy/mkIQp7AD0RArDGAJ919vcED3m7paMtlPBXwHjCWbprzwCgnZte
Pu8OmtHJq1fMud/glx9z/K0=
=gOyq
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



tetzlav schrieb:
> Alexander Morlang schrieb:
>> Daniel Poelzleithner schrieb:
>>> here in leipzig we already layed the ground stones for a widespanning,
>>> redundant dns network using anycast ips for redundancy.
>>> http://wiki.freifunk.net/FF-Zone
>> thats less then i thought:
>> (Dieser Artikel enthält momentan keinen Text)
> 
> -> http://wiki.freifunk.net/FF-zone
> 
> ;)
> 

Sorry, but this does not look like a decentral "all are equal" solution,
more like a centralized service.

i think, something like the olsr-bmf would be more interesting, it gets
metrics from the underlying meshrouting protocol but does its own
message forwarding.

> Regards
> tetzlav
> 
Greets, Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp2bchx2RbV7T5aERAo0qAKCN93khw3A9Jjj3UggGBTCLviwCxwCgxqv4
o27yznmprm2tzyB8ZKMdWrE=
=h6UG
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Morlang wrote:

> Sorry, but this does not look like a decentral "all are equal" solution,
> more like a centralized service.

yes, some sort of. there is a master dns server that ensures uniquiness
of domains and at least knows how is responsible for the zones. nothing
forbids you to mirror the zones on all nodes, i just don't see any sense
in it. 4-5 slave servers should be enough even for a large city. every
zone admin can run his own masters if he wish to.
responses will be fast and redundant even if some of them die. and you
can use real dns software and can run really large zones with large
entries without wasting pressures router ram. reverse dns, dyndns, like
my notebooks is always aestas.poelzi.ff if its somewhere in freifunk...
very cool stuff. dns loc records, very nice. combined with reverse dns
allows very rfc conform routings visualisations... even can show nodes
that are offline....

> i think, something like the olsr-bmf would be more interesting, it gets
> metrics from the underlying meshrouting protocol but does its own
> message forwarding.

what does bmf have to do with dns. if you think about forwarding name
entries as broadcasts: this is just a wast of bandwidth. i don't even
start to think about renaming my node to www.google.de and see what
happens ;)

kindly regards
 daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp2oCy/mkIQp7AD0RAstwAJ4rptMfmyEGLpFbQRVKPcLB4yIafACg3hPi
GJ7T8PzUGVpO8Cfh9A/mj9A=
=Zv8z
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Daniel Poelzleithner schrieb:
> Alexander Morlang wrote:
> 
>> Sorry, but this does not look like a decentral "all are equal" solution,
>> more like a centralized service.
> 
> yes, some sort of. there is a master dns server that ensures uniquiness
> of domains and at least knows how is responsible for the zones. nothing
> forbids you to mirror the zones on all nodes, i just don't see any sense
> in it. 4-5 slave servers should be enough even for a large city. every
> zone admin can run his own masters if he wish to.
> responses will be fast and redundant even if some of them die. and you
> can use real dns software and can run really large zones with large
> entries without wasting pressures router ram. reverse dns, dyndns, like
> my notebooks is always aestas.poelzi.ff if its somewhere in freifunk...
> very cool stuff. dns loc records, very nice. combined with reverse dns
> allows very rfc conform routings visualisations... even can show nodes
> that are offline....

with the small sideeffect of a small group controlling the a-server.

> 
>> i think, something like the olsr-bmf would be more interesting, it gets
>> metrics from the underlying meshrouting protocol but does its own
>> message forwarding.
> 
> what does bmf have to do with dns. if you think about forwarding name
> entries as broadcasts: this is just a wast of bandwidth. i don't even
> start to think about renaming my node to www.google.de and see what
> happens ;)

in opposite of the name plugin wich uses olsr for flooding informations,
bmf does its own flooding. as batman does not support flooding custom
payload, this would be the only way of distributing information
efficient and decentral as long there is a way to get the metrics from
the routing protocol.

And, of course, who are you, desciding for me what a waste of bandwith
in my case ist? ;-)


> 
> kindly regards
>  daniel

cu in finowfurt, alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp3TZhx2RbV7T5aERAsshAJ0XUiQxil/EnLspvS488WSCxFSJjwCfYmuh
Rip12GW8r2ayJa97EsngHxQ=
=17xF
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[clauz]

2007/7/25, Alexander Morlang <alx@dd19.de>:
> Sorry, but this does not look like a decentral "all are equal" solution,
> more like a centralized service.
>
> i think, something like the olsr-bmf would be more interesting, it gets
> metrics from the underlying meshrouting protocol but does its own
> message forwarding.

Yes, something like the olsr-bmf + zeroconf solution...

Ciao,
Claudio

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Morlang wrote:


> with the small sideeffect of a small group controlling the a-server.

yes. i prefer a group of people i can trust controlling the a-server
then trusting every packet someone, somewhere in the network is sending.
hello, i'm www.google.de, how are you :)
by the way, ok, with hna annoucements faking some site is still easy,
but just because one instance of the network has problems, there is no
need to repeat ourself. i.e. dnssec for example.


> in opposite of the name plugin wich uses olsr for flooding informations,
> bmf does its own flooding. as batman does not support flooding custom
> payload, this would be the only way of distributing information
> efficient and decentral as long there is a way to get the metrics from
> the routing protocol.

by the way, is see it comming. packetstorms through circular broadcast
packets. i have SEEN links that have 1.5 seconds delay, god knows why.
two of those and you crack the duplicate lookup buffer...

i'm not against broadcast in general. but everything i get which i'm
actually not interested in, or is duplicated information (something i
already know), is simply a wast of bandwidth. It's easy to say, ohh,
some bytes here, some bytes there. if you look at a real mesh, you
simply see to much useless traffic. there are nodes in freifunk leipzig,
that have 80kb/s olsr traffic. 80kb/s, some people would dream about
this speed, but just wasted away....

kindly regards
 daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp4dyy/mkIQp7AD0RAnf8AKCMSfalwb81SOoq2DTvntK4c8nhqQCggAQo
CzV7Nu+t2wdCx6V3tKpaImk=
=/JIy
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Daniel Poelzleithner schrieb:
> Alexander Morlang wrote:
> 
> 
>> with the small sideeffect of a small group controlling the a-server.
> 
> yes. i prefer a group of people i can trust controlling the a-server
> then trusting every packet someone, somewhere in the network is sending.
> hello, i'm www.google.de, how are you :)
> by the way, ok, with hna annoucements faking some site is still easy,
> but just because one instance of the network has problems, there is no
> need to repeat ourself. i.e. dnssec for example.

i distrust central structures, doing it decentral is one of the main
things in meshnetworking. It sounds, you want to establish centralized
structures of power for security reasons and telling about the nice
advantage of reliability.

sounds familiar, i think we both are fighting against this things in
realworld, so i do not want to introduce it in the freifunk world.

> 
> 
>> in opposite of the name plugin wich uses olsr for flooding informations,
>> bmf does its own flooding. as batman does not support flooding custom
>> payload, this would be the only way of distributing information
>> efficient and decentral as long there is a way to get the metrics from
>> the routing protocol.
> 
> by the way, is see it comming. packetstorms through circular broadcast
> packets. i have SEEN links that have 1.5 seconds delay, god knows why.
> two of those and you crack the duplicate lookup buffer...

Thats a specific problem of implementation wich could be solved.

> 
> i'm not against broadcast in general. but everything i get which i'm
> actually not interested in, or is duplicated information (something i
> already know), is simply a wast of bandwidth. It's easy to say, ohh,
> some bytes here, some bytes there. if you look at a real mesh, you
> simply see to much useless traffic. there are nodes in freifunk leipzig,
> that have 80kb/s olsr traffic. 80kb/s, some people would dream about
> this speed, but just wasted away....

sure, imagine a bunch of 20 nodes periodically polling all nodes for
decentral information, because they do not trust the central instance,
how much traffic would that be? and, you cannot do anything against it,
except censorship on ip-level.

> 
> kindly regards
>  daniel
> 
cu, alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqJSVhx2RbV7T5aERAvTKAKC8pkBRiIcEvPhox05FR5icei0HHACffqMz
UQpa9DBvzKrQzlhL/sckelw=
=4+zs
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Hi,


this question was a bit forgotten.  :-)

> how does batmand detect whether the internet connection is really connected
> to the internet or not. Or does batmand just relays on the -g parameter.
> Until now we let run a cron job that checks for the real working
> gateway. Because we can not relay on the presence of the default
> route. User may use a different
> router to connect to the internet and just add the default route this
> private router.
> The problem is that the node offering a internet connection (-g)
> should also be able to access other internet connection if its local
> connection is brocken.

First of all, "-g" is just flooded through the network. We also want some kind 
of "dyngw"-plugin but with a better approach: By using tunnels to the gateway 
batman is in a far better situation than OLSR. The "is internet really 
available" check can be done on the client side and is therefore much more 
reliable. With batman 0.3 all the packet flow towards and from the internet 
is going through batman. Batman just has to check whether traffic is coming 
back through the tunnel after sending packets to the internet. If this is not 
the case the batman node offering the internet is blacklisted and another 
gateway is chosen.
This has not been implemented yet but all the neccessary basics for that 
feature are completed by now. Expect this feature to come in the following 
weeks.

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Aaron Kaplan]

On Jul 27, 2007, at 4:07 PM, Marek Lindner wrote:

>  By using tunnels to the gateway
> batman is in a far better situation than OLSR


guys, please mention, that in OLSRd this is simply problematic for  
you in *Berlin* where you use private IPs.
And therefore the NAT causes problems. The tunnel trick works  
*just*as*well* for OLSRd BTW.

I just often have the feeling that you want to dissmiss olsrd becasue  
batman *has* to be better, since it is already in the name. That  
sucks a bit. Well, whatever...

I think both approaches have something to it. OLSRd is well tested  
(and has ugly code, yes) but batman really has to be still tested out  
in the wild with many nodes. A routing protocol evolves with the load  
that is applied to it.
That is the key issue in my opinion.

Anything new with the approaches to create an RFC for batman by the way?

ciao,
aaron.

RE: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Lui]

Marek,

>First of all, "-g" is just flooded through the network. We 
>also want some kind of "dyngw"-plugin but with a better approach:
>By using tunnels to the gateway batman is in a far better situation
>than OLSR. The "is internet really available" check can be done on
>the client side and is therefore much more 

it's about the gateway himself (not a client-of-the-gateway).
A gateway router (has to/)should check his default route and change
his role to 'ordinary-client' => switch working state from -g to
-r/-p Mode. May think about NATed LAN-clients, too...

The "working-tunnel-check" is good tool against 'vandalism' or
mis-configuration in the hand of a gateway-client, but it's no
protection for the gateway against vandalism (i.e.) of his ISP...

Lui
(stucking just in the mentioned situation)

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Hi,


> guys, please mention, that in OLSRd this is simply problematic for
> you in *Berlin* where you use private IPs.

the majority of all wireless mesh networks out there don't have a good 
relationship to an ISP which routes all the traffic and sponsors public 
IPs ...
I really think you have a nice solution in Vienna which unfortunately is not 
reproducible everywhere.


> And therefore the NAT causes problems. The tunnel trick works
> *just*as*well* for OLSRd BTW.

So far OLSRd has no builtin tunnel functionality and that's why you can't do 
the same trick.
By the way, you should know that the dyngw plugin is real pain. Too often it 
enables or disables the Internet connection where this is totally 
unneccessary. And it does not solve the problem. It just tries to hide a flaw 
because I rely on the information the gateway sends me.


> I just often have the feeling that you want to dissmiss olsrd becasue
> batman *has* to be better, since it is already in the name. That
> sucks a bit. Well, whatever...

Aaron, please don't feel personally attacked by this. You know that we started 
batman because we were not happy with many things in OLSR. 
The only reason for me to mention OLSR was that many people here expect us to 
redo all the things OLSR does. And I just want to remind them that batman is 
a different project.


> I think both approaches have something to it. OLSRd is well tested
> (and has ugly code, yes) but batman really has to be still tested out
> in the wild with many nodes. A routing protocol evolves with the load
> that is applied to it.
> That is the key issue in my opinion.

I absolutely agree.


> Anything new with the approaches to create an RFC for batman by the way?

We are working on it.

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Hi,


> it's about the gateway himself (not a client-of-the-gateway).
> A gateway router (has to/)should check his default route and change
> his role to 'ordinary-client' => switch working state from -g to
> -r/-p Mode. May think about NATed LAN-clients, too...

this is quite difficult to implement. The dyngw plugin tries to do exactly the 
same thing. Various approaches were already tested and they all had their 
problems. How do you want to find out whether internet is available or not ? 
Ping, traceroute or dns ? As far as I remember we always had situations where 
this detection failed.
The latest example: Run OLSR with the dyngw plugin on a batman host which is 
searching for internet (-r). The plugin will find out that internet is 
available via batman and happily announces a default route in the OLSR 
network ...

I think the difficult part are the endless scenarios we would have to cover. 
But if someone has a good idea I certainly will implement it.  :-)

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Aaron Kaplan]

>
>> I just often have the feeling that you want to dissmiss olsrd becasue
>> batman *has* to be better, since it is already in the name. That
>> sucks a bit. Well, whatever...
>
> Aaron, please don't feel personally attacked by this. You know that  
> we started
> batman because we were not happy with many things in OLSR.
>
I don't feel personally attacked at all :)
I just again and again get the feeling from batman people that sort  
of "everything else sucks"
Like academia sucks, olsr sucks etc etc.
But that is a bit contra-productive. That is what I wanted to point out.

I also know that olsrd has its short comings (after all it was a  
diploma thesis)... but nevertheless,
you must admit: it did its job marvelously. Without it we could not  
have created our nice networks.

Of course, it it time to look into new directions (as well as enhance  
the existing code).


> The only reason for me to mention OLSR was that many people here  
> expect us to
> redo all the things OLSR does. And I just want to remind them that  
> batman is
> a different project.
>
nono... redo everything is like asking for a bit to much. Agreed. But  
step by step...

>
>> I think both approaches have something to it. OLSRd is well tested
>> (and has ugly code, yes) but batman really has to be still tested out
>> in the wild with many nodes. A routing protocol evolves with the load
>> that is applied to it.
>> That is the key issue in my opinion.
>
> I absolutely agree.
>
>
>> Anything new with the approaches to create an RFC for batman by  
>> the way?
>
> We are working on it.
>
> Regards,
> Marek
>
> _______________________________________________
> 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
>

---
C.O.S.H.E.R. - Completely Open Source Headers Engineering and Research

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Am Freitag, 27. Juli 2007 18:03 schrieb Aaron Kaplan:
> I don't feel personally attacked at all :)

But the unknown reader might get that impression ...


> I just again and again get the feeling from batman people that sort
> of "everything else sucks"
> Like academia sucks, olsr sucks etc etc.
> But that is a bit contra-productive. That is what I wanted to point out.

Where does this feeling come from ?

Because of "better approach to mobile ad-hoc networking" (you said: "since it 
is already in the name") ?! Do you have in mind what OLSR means ? OPTIMIZED 
Link State routing - that means OLSR is the first link state routing protocol 
which optimizes ?!

GNU = Gnu is Not Unix => is Unix bad ?
KDE => Kool Desktop Environment => the others are not cool ?
VIM => Vi IMproved => vi seems to be bad ?!

We could continue this list a very long time.


Or is it because we always compare with OLSR ?
Don't forget that OLSR is the de-facto standard for routing protocols. So, we 
compare against something the people know. Have you ever listened to a SVN 
talk ? They compare to CVS. What is so bad about showing real problems in 
existing solutions and offering something better ?

Please remember - OLSR is so good and well known because we helped it quite a 
lot. Much of the intial testing was done in Berlin. Afterwards we disabled 
MPR and Hysteris, developed ETX and Fisheye. It is not your child only. It 
was not easy for us to find out that we have to restart from scratch if we 
really want to solve the problems OLSR has. 
We learned a lot from it and now we move on.


> nono... redo everything is like asking for a bit to much. Agreed. But
> step by step...

I meant they want us to clone the way OLSR solves certain problems and we 
don't want that. It may need some time and effort but we want to attack the 
real source of the problems.

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Aaron Kaplan]

On Jul 27, 2007, at 6:40 PM, Marek Lindner wrote:

> Am Freitag, 27. Juli 2007 18:03 schrieb Aaron Kaplan:
>> I don't feel personally attacked at all :)
>
> But the unknown reader might get that impression ...
>
>
>> I just again and again get the feeling from batman people that sort
>> of "everything else sucks"
>> Like academia sucks, olsr sucks etc etc.
>> But that is a bit contra-productive. That is what I wanted to  
>> point out.
>
> Where does this feeling come from ?
>
I think there has been enough academia bashing (completely useless!)  
in the past.
If you look up the old mails then you know what I mean. I am quite  
convinced that academia already overtook
the freifunk style networks some time ago! And you just don't notice it.

Again: I do NOT really think about OLSR so much in particular.
I just wanted to give you some feedback.
You could also sum the feedback up as:

   "Hochmut/Arroganz kommt vor dem Fall"

I hope I am wrong.

nevertheless, I am very curious when the next real world tests come out.
Well, again. Just my personal feelings and observations. I hope I am  
wrong.

ciao,
a.

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Axel Neumann]

Hello,

On Friday 27 July 2007 22:41, Aaron Kaplan wrote:
> >> I just again and again get the feeling from batman people that sort
> >> of "everything else sucks"
> >> Like academia sucks, olsr sucks etc etc.
> >> But that is a bit contra-productive. That is what I wanted to
> >> point out.
> >
> > Where does this feeling come from ?
>
> I think there has been enough academia bashing (completely useless!)
> in the past.
> If you look up the old mails then you know what I mean. 

Sorry, I still have difficulties to understand. I looked up the old mails (of 
this mailing list) and found only one mail mentioning "academic" and that was 
in march, so i am not sure if you are referring to that. 

Anyway, if there was bashing (on whatever) then I am sorry, but it also would 
be just fair to give a reasonable hint (in a reasonable time) to the 
statements that caused the bad feelings. Otherwise it causes just reproaches 
without leaving a chance to defend/explain and even worse at a time where 
nobody remembers what the actual thread was about.
The same applies to olsr but here i want to add that comparing batman with 
existing state of the art solutions is usual and wanted. I admit , personally 
I might be a bit biased but thats why we have this public mailing list, so 
that everybody can question the given statements and come up with precise and 
concrete counter arguments.

> I am quite 
> convinced that academia already overtook
> the freifunk style networks some time ago! And you just don't notice it.

Can you provide further (background-)links on that (especially interesting 
would be those based on real world tests as addressed below)?

best regards,
axel

> Again: I do NOT really think about OLSR so much in particular.
> I just wanted to give you some feedback.
> You could also sum the feedback up as:
>
>    "Hochmut/Arroganz kommt vor dem Fall"
>
> I hope I am wrong.
>
> nevertheless, I am very curious when the next real world tests come out.
> Well, again. Just my personal feelings and observations. I hope I am
> wrong.
>
> ciao,
> a.
>
>
>
>
> _______________________________________________
> 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.] dynamic gateway / hna / services

[Axel Neumann]

Hello,

On Dienstag 24 Juli 2007, Freifunk Dresden wrote:
[...]
> Question 2:
>
> I'm currently checking how the HNA is working, but until now I can not
> see any HNA on a second node. Firewall is enabled completely for both
> nodes and each node sees the other nodes. I call batmand as follow:
> Node1: batmand -t 63 -a 141.56.0.0/16 wlan0 bbs /t 2 bbc /t 2
> Node2: batmand -t 63 eth1 bbs /t 2 bbc /t 2
>
> But batmand -c -d 4 does not show any HNA messages and no HNA entry is
> stored in   routing table.

Indeed, seemed something has been missed (sorry for late reply). 
Can you try something above rv489 

debul-level 3 should show (batmand -c -d 3):
Adding route to 10.20.0.222/32 via 10.20.0.2 (table 65 - eth0:bat)
and 
ip route ls table 65
10.20.0.222 via 10.20.0.2 dev eth0  proto static

> Beside of this the Idea to add/delete HNA without stopping batmand
> would be good. e.g. batmand -c -a <add-hna>
>             batmand -c -A <del-hna>

I also like the idea of dynamically changing some parameters but on the other 
hand, what are the negative side-effects of restarting a daemon ? 
 - A client connected to the daemon might temporary loose connection
 - Do you know others?

[...]

>
> Another Idea of the "-m" is to differenciate this parameter to -M
> <"message"> and -m <send-script>. by calling batmand -c -m send-script,
> batmand can setup stdin/stdou as binary file handle and fill a user-OGM
> with binary data that is then send.
>

Even if such message-flooding ist not implemented I just thought of whether 
there exist some standardized formats to announce such services (maybe the 
community network markup language CNML idea) ? 

ciao, 
axel

[B.A.T.M.A.N.] dynamic gateway / hna / services

[Freifunk Dresden]

Hello,
I didn't get the email for this request, so the mailling list thread  
my be brocken.


> n Dienstag 24 Juli 2007, Freifunk Dresden wrote:
> [...]
> > Question 2:
> >
> > I'm currently checking how the HNA is working, but until now I can not
> > see any HNA on a second node. Firewall is enabled completely for both
> > nodes and each node sees the other nodes. I call batmand as follow:
> > Node1: batmand -t 63 -a 141.56.0.0/16 wlan0 bbs /t 2 bbc /t 2
> > Node2: batmand -t 63 eth1 bbs /t 2 bbc /t 2
> >
> > But batmand -c -d 4 does not show any HNA messages and no HNA entry is
> > stored in   routing table.
>
> Indeed, seemed something has been missed (sorry for late reply). Can  
> you try something above rv489 debul-level 3 should show (batmand -c  
> -d 3):
> Adding route to 10.20.0.222/32 via 10.20.0.2 (table 65 - eth0:bat)
> and ip route ls table 65
> 10.20.0.222 via 10.20.0.2 dev eth0  proto static

I have checked out the rv491 and it seems working. In my test environment I
use a laptop (i386) and two wrt54gl. The wrt shows at "-d3" that the announced
HNA is added/deleted every 1-5 seconds. The wrt that has a greater  
distance (5meter 2 walls between) adds and deletes the HNA in a highe  
frequency than the
wrt that is about 50cm away.
I think that HNA should not be deleted to fast because someone that is  
using this "bad" connection will get often error messages during  
surfing that the rout e is not found. It would be better if just the  
connection slow because of transmistion errors.



> > Beside of this the Idea to add/delete HNA without stopping batmand
> > would be good. e.g. batmand -c -a <add-hna>
> >             batmand -c -A <del-hna>
>
> I also like the idea of dynamically changing some parameters but on  
> the other hand, what are the negative side-effects of restarting a  
> daemon ?  - A client connected to the daemon might temporary loose  
> connection
>  - Do you know others?

I think the first point is important enough. see the statement above.

> [...]
>
> >
> > Another Idea of the "-m" is to differenciate this parameter to -M
> > <"message"> and -m <send-script>. by calling batmand -c -m send-script,
> > batmand can setup stdin/stdou as binary file handle and fill a user-OGM
> > with binary data that is then send.
> >
>
> Even if such message-flooding ist not implemented I just thought of  
> whether there exist some standardized formats to announce such  
> services (maybe the community network markup language CNML idea) ?  
> ciao, axel

I have looked through the code and have seen that the HNA is simply  
appended to
the end of a message. if we want to send other information a TLV structure is
needed (Tag-length-value). Batmand can ignore unknown Tags and is  
still working in the network. At moment the whole network needs an  
update at same time, because old batmand will interpret any data as HNA.
I hope I'm not wrong :)

Bye
  Stephan

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Axel Neumann]

Hello!

On Freitag 03 August 2007, Freifunk Dresden wrote:
> Hello,
> I didn't get the email for this request, so the mailling list thread
> my be brocken.
strange, anybody else experienced problems?

[...]

> > > I'm currently checking how the HNA is working, but until now I can not
[...]
> I have checked out the rv491 and it seems working. In my test environment I
> use a laptop (i386) and two wrt54gl. The wrt shows at "-d3" that the
> announced HNA is added/deleted every 1-5 seconds. The wrt that has a
> greater distance (5meter 2 walls between) adds and deletes the HNA in a
> highe frequency than the
> wrt that is about 50cm away.
> I think that HNA should not be deleted to fast because someone that is
> using this "bad" connection will get often error messages during
> surfing that the rout e is not found. It would be better if just the
> connection slow because of transmistion errors.

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? 

> > [...]
> >
> > > Another Idea of the "-m" is to differenciate this parameter to -M
> > > <"message"> and -m <send-script>. by calling batmand -c -m send-script,
> > > batmand can setup stdin/stdou as binary file handle and fill a user-OGM
> > > with binary data that is then send.
> >
> > Even if such message-flooding ist not implemented I just thought of
> > whether there exist some standardized formats to announce such
> > services (maybe the community network markup language CNML idea) ?
> > ciao, axel
>
> I have looked through the code and have seen that the HNA is simply
> appended to
> the end of a message. if we want to send other information a TLV structure
> is needed (Tag-length-value). Batmand can ignore unknown Tags and is
> still working in the network. At moment the whole network needs an
> update at same time, because old batmand will interpret any data as HNA.
> I hope I'm not wrong :)

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

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Marek Lindner]

Hi,


> > I also like the idea of dynamically changing some parameters but on
> > the other hand, what are the negative side-effects of restarting a
> > daemon ?  - A client connected to the daemon might temporary loose
> > connection
> >  - Do you know others?
>
> I think the first point is important enough. see the statement above.

at the moment we have more important issues to address than a broken debug 
client connection I think. But we happily accept patches if ou want to 
improve the current situation. 
Note: This problem is more complicated than it might seem. You will have to 
pay attention to various race conditions.


> I have looked through the code and have seen that the HNA is simply
> appended to
> the end of a message. if we want to send other information a TLV structure
> is needed (Tag-length-value). Batmand can ignore unknown Tags and is
> still working in the network. At moment the whole network needs an
> update at same time, because old batmand will interpret any data as HNA.
> I hope I'm not wrong :)

You are right. But why should we append random data to flood the network ? Why 
can't we use _existing_ and _working_ solutions for service discovery ?
Did you read the discussion regarding this topic which was started by you ?

Regards,
Marek

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Freifunk Dresden]

> 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

Re: [B.A.T.M.A.N.] dynamic gateway / hna / services

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Axel Neumann schrieb:
> Hello!
> 
> On Freitag 03 August 2007, Freifunk Dresden wrote:

<removed>

> 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.

maybe a additional byte is enough to tell, that other nodes can query
service information. this would result in less overhead than announcing
services in OGM and is also less overhead than polling all nodes for
services.

It would also leave enough room for announcing different service
advertisement systems in this byte.

> 
> 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
>

Greets, alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyZKohx2RbV7T5aERAn4DAJ41fmMlKiOHhjuFvmHZPJefa2C7uACdEdx2
yfPQKQt3ICcJZh8BDGGoPzc=
=zOak
-----END PGP SIGNATURE-----