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
-----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 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.
thats less then i thought: (Dieser Artikel enthält momentan keinen Text)
kindly regards Daniel
greets, alex
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.
thats less then i thought: (Dieser Artikel enthält momentan keinen Text)
-> http://wiki.freifunk.net/FF-zone
;)
Regards tetzlav
-----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 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 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 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 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexander Morlang wrote:
thats less then i thought: (Dieser Artikel enthält momentan keinen Text)
;)
http://wiki.freifunk.net/FF-zone
greetings daniel
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
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
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.
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
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
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
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.
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
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)
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
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@lists.open-mesh.org
-
Aaron Kaplan -
Alexander Morlang -
Axel Neumann -
clauz＠ninux.org -
Daniel Poelzleithner -
Freifunk Dresden -
Lui -
Marek Lindner -
tetzlav