7 May
2008
7 May
'08
12:17 p.m.
Hi all.
I have made a new version of the patch posted by acinonyx (rv502),
for interfacing batmand with the zebra routing daemon. There are 2
versions available: One for the latest svn (rv1060) and one for the
stable 0.3 release. Take a look at:
http://www.cslab.ece.ntua.gr/~chazapis/batman/
Please consider this code experimental. Some initial tests are
promising,
but there may be bugs... :)
For now, the plug-in just supports sending routes to zebra, not the
opposite (redistributing routes from other protocols). That was also
the case with the older - rv502 - version.
What the patch does is:
- Adds a flag "-z" to the batmand executable which may be used to
enable zebra communication and accepts as an argument the
path to the corresponding zebra unix-domain socket.
- If zebra is enabled:
- No rules are added to the kernel.
- All UNICAST routes are sent to zebra.
All routes are also sent to the kernel (in linux/route.c), but the extra
routing tables are not used by linux, because of the lack of rules.
These routing tables remain, just to help with route management,
so batmand can successfully remove all added routes on shutdown.
Antony
7 May
7 May
12:41 p.m.
Hi,
I have made a new version of the patch posted by
acinonyx (rv502),
for interfacing batmand with the zebra routing daemon. There are 2
versions available: One for the latest svn (rv1060) and one for the
stable 0.3 release. Take a look at:
http://www.cslab.ece.ntua.gr/~chazapis/batman/
it looks good - thanks for your work. I would like to put your changes on
open-mesh.net. Either linking to your webspace or copying your work on our
server. What do you prefer ?
What the patch does is:
- Adds a flag "-z" to the batmand executable which may be used to
enable zebra communication and accepts as an argument the
path to the corresponding zebra unix-domain socket.
- If zebra is enabled:
- No rules are added to the kernel.
- All UNICAST routes are sent to zebra.
Did you consider using the "--policy-routing-script" for this communication
with zebra ? You could write an external program that gets the information
from batman and relays them to zebra. Therefore, you would not need to patch
every batman installation and would not have to change your patches every
time when batman changes. By using this facility you can decide what routes
are sent to zebra, what routes are added to the routing table and you don't
need to worry about batman. This communication interface could also be used
by other routing protocols without the need of reinventing the wheel over and
over again.
Greetings,
Marek
1 p.m.
On May 7, 2008, at 3:41 PM, Marek Lindner wrote:
I had a lengthy conversation about that with Acinonyx. The first patch
I did was to
enable us to pass arguments to the policy routing script. However, I
preferred a
direct patch, because I couldn't find an easy way with the current
batmand and
(more importantly) the zebra interface to retrieve routes on exit. I
had to
implement some kind of route management/tracking in the script and
delete these
routes on shutdown. With the direct patch, route management is done in
the kernel.
Sure, a full-featured policy-routing-script would be a more
appropriate solution
and I hope to find some time to do it in the future.
An even greater challenge would be to implement a bidirectional policy-
routing-script,
that could also be used to implement route redistribution from other
protocols.
Which would of course require a full API to talk with batmand... Need
even more time for that... :)
Cheers,
Antony
Hi,
I would prefer that you copy it over. I think it is better to keep
things in one place. :)
I have made a new version of the patch posted by
acinonyx (rv502),
for interfacing batmand with the zebra routing daemon. There are 2
versions available: One for the latest svn (rv1060) and one for the
stable 0.3 release. Take a look at:
http://www.cslab.ece.ntua.gr/~chazapis/batman/
it looks good - thanks for your work. I would like to put your
changes on
open-mesh.net. Either linking to your webspace or copying your work
on our
server. What do you prefer ?
What the patch does is:
- Adds a flag "-z" to the batmand executable which may be used to
enable zebra communication and accepts as an argument the
path to the corresponding zebra unix-domain socket.
- If zebra is enabled:
- No rules are added to the kernel.
- All UNICAST routes are sent to zebra.
Did you consider using the "--policy-routing-script" for this
communication
with zebra ? You could write an external program that gets the
information
from batman and relays them to zebra. Therefore, you would not need
to patch
every batman installation and would not have to change your patches
every
time when batman changes. By using this facility you can decide what
routes
are sent to zebra, what routes are added to the routing table and
you don't
need to worry about batman. This communication interface could also
be used
by other routing protocols without the need of reinventing the wheel
over and
over again.
Greetings,
Marek
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
1:29 p.m.
I would prefer that you copy it over. I think it is
better to keep
things in one place. :)
Ok, I copied it and put a note on the website. See:
https://www.open-mesh.net/batman/patches
I renamed the patches from "experimental" to "needs-testing" otherwise
people
might get confused with our experimental branch.
I had a lengthy conversation about that with Acinonyx.
The first patch
I did was to enable us to pass arguments to the policy routing script.
However, I preferred a direct patch, because I couldn't find an easy way
with the current batmand and (more importantly) the zebra interface to
retrieve routes on exit. I had to implement some kind of route
management/tracking in the script and delete these
routes on shutdown. With the direct patch, route management is done in
the kernel. Sure, a full-featured policy-routing-script would be a more
appropriate solution and I hope to find some time to do it in the future.
But batman should keep track of all routes and send the delete commands to
your program. On exit batman should notify your program about all the routes
to be deleted. If not you found a bug. ;-)
An even greater challenge would be to implement a
bidirectional policy-
routing-script, that could also be used to implement route redistribution
from other protocols.
Which would of course require a full API to talk with batmand... Need
even more time for that... :)
You mean batman should distribute zebra routes on the fly ? That is possible -
even _today_. :-)
You can add and delete HNA routes via the unix socket. HNA is a way to flood
the batman network with routes which do not belong to batman.
Greetings,
Marek
2:10 p.m.
On May 7, 2008, at 4:29 PM, Marek Lindner wrote:
This is not a bug, but an implementation restriction. Batmand uses
flush_routes_rules (in linux/route.c) to get back all all routes that
have been added to the kernel during execution and from there it calls
add_dell_route to remove them. When using the policy-routing-script,
nothing is removed, as nothing has been added to the kernel. It is
supposed to be the responsibility of the policy-routing-script to know
what has to be deleted. If there was a way to simply tell zebra:
"Delete all routes from batman", that wouldn't be a problem. But I
don't
know how to do this with the zebra API and I didn't wan't to keep track
of all routes in the script, as this is already implemented in batmand.
I hadn't though about that. I'll give it a try.
You could also consider merging
http://www.cslab.ece.ntua.gr/~chazapis/batman/batman-r1040-policy-routing-s…
into the main branch. It allow for passing args to the policy-routing-
script, which is really useful.
Antony
I would prefer that you copy it over. I think it
is better to keep
things in one place. :)
Ok, I copied it and put a note on the website. See:
https://www.open-mesh.net/batman/patches
I renamed the patches from "experimental" to "needs-testing"
otherwise people
might get confused with our experimental branch.
I had a lengthy conversation about that with
Acinonyx. The first
patch
I did was to enable us to pass arguments to the policy routing
script.
However, I preferred a direct patch, because I couldn't find an
easy way
with the current batmand and (more importantly) the zebra interface
to
retrieve routes on exit. I had to implement some kind of route
management/tracking in the script and delete these
routes on shutdown. With the direct patch, route management is done
in
the kernel. Sure, a full-featured policy-routing-script would be a
more
appropriate solution and I hope to find some time to do it in the
future.
But batman should keep track of all routes and send the delete
commands to
your program. On exit batman should notify your program about all
the routes
to be deleted. If not you found a bug. ;-)
An even greater challenge would be to implement a
bidirectional
policy-
routing-script, that could also be used to implement route
redistribution
from other protocols.
Which would of course require a full API to talk with batmand... Need
even more time for that... :)
You mean batman should distribute zebra routes on the fly ? That is
possible -
even _today_. :-)
You can add and delete HNA routes via the unix socket. HNA is a way
to flood
the batman network with routes which do not belong to batman.
Greetings,
Marek
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
1:49 p.m.
Hello
Antony Chazapis wrote:
For now, the plug-in just supports sending routes to
zebra, not the
opposite (redistributing routes from other protocols). That was also
the case with the older - rv502 - version.
Marek Lindner wrote:
You mean batman should distribute zebra routes on the
fly ? That is possible -
even _today_. :-)
You can add and delete HNA routes via the unix socket. HNA is a way to flood
the batman network with routes which do not belong to batman.
I am mainly interested in redistributing zebra routes to batman as i do
with olsr_quagga plugin. This way, i can think about switching from olsr
to batman 0.3. Perhaps, you will enable it in your code again.
Thx
Daniel
--
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management
2:03 p.m.
Hi,
I am mainly interested in redistributing zebra routes
to batman as i do
with olsr_quagga plugin. This way, i can think about switching from olsr
to batman 0.3. Perhaps, you will enable it in your code again.
it was never "enabled" - it was part of a patch.
I'm not that familiar with zebra/quagga. Can you explain what you need and why
the dynamic HNA adding/deleting is not enough ? That feature did not exist in
revision 502.
Greetings,
Marek
4:17 p.m.
Hey Marek
Marek Lindner wrote:
Enabling zebra to tell batmand to add/remove routes needs a patch in
zebra. It would be really nice to have a batmand plugin whatever that
talks to zebra for getting dynamic HNA routes. So i dont have to modify
my zebra, but can enable a plugin in batmand (as it is in OLSR).
I need this for BGP routing. Imagine to route two batmand clouds
together via BGP. If the third cloud joins, i dont want to reconfigure
the other batmand-daemons. They just grep the routes from the running zebra.
Another big option would be to let zebra speak batman / olsr protocol
and be able to configure batman / olsr through zebra interface /
configuraion. But that would be "top of everything" and imo not necessary.
Greetz
Daniel
--
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management
I am mainly
interested in redistributing zebra routes to batman as i do
with olsr_quagga plugin. This way, i can think about switching from olsr
to batman 0.3. Perhaps, you will enable it in your code again.
it was never
"enabled" - it was part of a patch.
I'm not that familiar with zebra/quagga. Can you explain what you need and why
the dynamic HNA adding/deleting is not enough ? That feature did not exist in
revision 502.
8 May
8 May
9:23 a.m.
Hi,
Enabling zebra to tell batmand to add/remove routes
needs a patch in
zebra. It would be really nice to have a batmand plugin whatever that
talks to zebra for getting dynamic HNA routes. So i dont have to modify
my zebra, but can enable a plugin in batmand (as it is in OLSR).
Your concept of "batman plugin" confuses me a bit. Is that a plugin in batman
or a plugin in zebra ? And what are the functions it provides which can't be
provided now and why ?
Greetings,
Marek
9:18 a.m.
Hello Marek
Marek Lindner wrote:
Its a batman plugin like an olsr plugin. zebra doesnt
provide any
plugins imo.
You provide a external switch to insert HNA by script. Unfortunately,
zebra cant call external script as i have to patch zebra then - or i
dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr
internally. thats something i like to see with batman-zebra-plugin.
Greetz
Daniel
--
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management
Enabling zebra
to tell batmand to add/remove routes needs a patch in
zebra. It would be really nice to have a batmand plugin whatever that
talks to zebra for getting dynamic HNA routes. So i dont have to modify
my zebra, but can enable a plugin in batmand (as it is in OLSR).
Your concept of "batman plugin" confuses me a bit. Is that a plugin in batman
or a plugin in zebra ? And what are the functions it provides which can't be
provided now and why ?
10:12 a.m.
Its a batman plugin like an olsr plugin. zebra doesnt
provide any
plugins imo.
You provide a external switch to insert HNA by script. Unfortunately,
zebra cant call external script as i have to patch zebra then - or i
dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr
internally. thats something i like to see with batman-zebra-plugin.
Batman does not provide any plugin interface as well. Simply because it is a
routing daemon and should only do that. On the other hand we don't like this
rewriting of plugins over and over again.
As already explained in the other part of this thread batman offers an
external interface for adding/deleting routing information which could be
used for that. A little external application can talk to zebra, add/delete
routes and/or HNA and could be _reused_ by other routing applications.
Greetings,
Marek
12 May
12 May
10:26 p.m.
I got some news.
I went the other way round and started out on an external program that
will act as an interface between batman and quagga. You can find it
here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
It is more of a sketch-of-proof right now and _should not be used for
deployment purposes_. The program is completely based on the
libraries provided by quagga, in contrast to the current patch and
the olsrd plug-in, that re-implement the API.
Assuming you have quagga installed, you can compile it with:
gcc -o batquagga batquagga.c -lzebra
Some systems may also require "-lcap" linked in.
What batquagga does is read from standard input the ROUTE commands
issued by batmand (--policy-routing-script) and issue the corresponding
route add/del messages to zebra. Note that I read 11 variables form
stdin,
which includes the "metric". So to use batquagga, you must have a batman
sources patched with the "...quagga.patch".
Moreover, batquagga can send redistribute requests to zebra, to
get routes by other protocols. For now, it just prints out the
routes, but
as you said it should be easy to invoke batmand from within the program
to add/del HNAs.
Now to the problem:
When exiting, I tell zebra to give me back the routes marked as "batman"
through a redistribute request. The purpose is to clear all batman-
originated
routes from the system. But zebra responds to a redistribute request
only
with the "selected" routes. So some entries are not echoed back.
After various hacks, I conclude that in order to properly implement
batquagga
I will either have to implement route-flushing in zebra, or I will
somehow have to
change batmand so that it will clear all HNAs on shutdown. The first
case
is easier and I will be trying to do that for now, but I guess the
second is "better".
Which leads me to a question to developers:
Do you keep or plan to keep network HNA information in batmand?
I mean, is there any way that flush_routes_rules (in linux/route.c)
could
be implemented in batmand, without the need of the external routing
table management?
As a routing daemon, batman, should keep track of the network state
in its
own structures, which in turn would ease porting to other platforms
as well.
As implemented, flush_routes_rules could be used for linux-specific
clean-up
on startup. Another function, completely os-agnostic, could be
implemented to
remove all batman-generated routes on shutdown. This is at least how all
quagga protocols are implemented.
Are there any plans on that?
Antony
(The batquagga name is credit of Acinonyx.)
On May 8, 2008, at 1:12 PM, Marek Lindner wrote:
Its a batman plugin like an olsr plugin. zebra
doesnt provide any
plugins imo.
You provide a external switch to insert HNA by script. Unfortunately,
zebra cant call external script as i have to patch zebra then - or i
dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr
internally. thats something i like to see with batman-zebra-plugin.
Batman does not provide any plugin interface as well. Simply
because it is a
routing daemon and should only do that. On the other hand we don't
like this
rewriting of plugins over and over again.
As already explained in the other part of this thread batman offers an
external interface for adding/deleting routing information which
could be
used for that. A little external application can talk to zebra, add/
delete
routes and/or HNA and could be _reused_ by other routing applications.
Greetings,
Marek
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
13 May
13 May
8:34 a.m.
Hi,
I went the other way round and started out on an
external program that
will act as an interface between batman and quagga. You can find it
here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
cooool !
Do you keep or plan to keep network HNA information in
batmand?
I mean, is there any way that flush_routes_rules (in linux/route.c)
could
be implemented in batmand, without the need of the external routing
table management?
Batman keeps track of the HNA and all other routes which were placed by batman
and deletes them individually. The mentionned function flush_routes_rules()
is only called during the startup to clean the tables and in case of a
segmentation fault because the internal data structures can't be trusted
anymore. The normal case is that batman deletes its own routes one by one.
I did some testing with a script which just prints the commands and I noticed
that the script can't execute those commands because it dies too quickly via
SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these
signals. Apart from that we have a little sync problem. Batman kills its
child after sending all the commands via the pipe. At that moment the child
may still be busy with processing these commands. We have to find an elegant
way to communicate that the child finished its last job. The latest revision
waits another 3 seconds which is far from being perfect ...
Greetings,
Marek
PS: Your addtional script arguments patch is an interesting idea. We are
checking on that because it might have some side effects.
9:14 a.m.
On May 13, 2008, at 11:34 AM, Marek Lindner wrote:
Hi,
That's great. My apologies I couldn't find that before.
I went the other way round and started out on an
external program
that
will act as an interface between batman and quagga. You can find it
here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
cooool !
Do you keep or plan to keep network HNA
information in batmand?
I mean, is there any way that flush_routes_rules (in linux/route.c)
could
be implemented in batmand, without the need of the external routing
table management?
Batman keeps track of the HNA and all other routes which were
placed by batman
and deletes them individually. The mentionned function
flush_routes_rules()
is only called during the startup to clean the tables and in case of a
segmentation fault because the internal data structures can't be
trusted
anymore. The normal case is that batman deletes its own routes one
by one.
I did some testing with a script which just prints the
commands and
I noticed
that the script can't execute those commands because it dies too
quickly via
SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these
signals. Apart from that we have a little sync problem. Batman
kills its
child after sending all the commands via the pipe. At that moment
the child
may still be busy with processing these commands. We have to find
an elegant
way to communicate that the child finished its last job. The latest
revision
waits another 3 seconds which is far from being perfect ...
I will take a look at that and see if I can do anything.
Thanks!
Antony
Greetings,
Marek
PS: Your addtional script arguments patch is an interesting idea.
We are
checking on that because it might have some side effects.
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
14 May
14 May
1:51 p.m.
On May 13, 2008, at 12:14 PM, Antony Chazapis wrote:
On May 13, 2008, at 11:34 AM, Marek Lindner wrote:
> I did some testing with a script which just prints the commands and
> I noticed
> that the script can't execute those commands because it dies too
> quickly via
> SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these
> signals. Apart from that we have a little sync problem. Batman
> kills its
> child after sending all the commands via the pipe. At that moment
> the child
> may still be busy with processing these commands. We have to find
> an elegant
> way to communicate that the child finished its last job. The latest
> revision
> waits another 3 seconds which is far from being perfect ...
>
I've checked out the latest revision and have seen the problem you
mention.
I think that waiting and then killing the process is not needed. If
you just
close the pipe, the other end should notice that there is an EOF at
stdin and die.
I created a new batquagga version (0.2) that does exactly that and even
when removing the "sleep" and "kill" commands from restore_defaults(),
it works fine.
Moreover, batquagga-0.2 has no signal handlers for SIGKILL and SIGINT.
They are not needed anymore. Also, the "retain routes" option was
removed
(no sense at this point, and no way to properly distinguish between
delete routes
that happen at shutdown vs. delete routes that would normally occur).
>
> PS: Your addtional script arguments patch is an interesting idea.
> We are
> checking on that because it might have some side effects.
>
The arguments patch or some other form of passing arguments is essential
for using the policy-routing-script to redistribute routes from other
protocols...
Antony
6:52 p.m.
I created a new batquagga version (0.2) that does
exactly that and even
when removing the "sleep" and "kill" commands from
restore_defaults(),
it works fine.
Unfortunately, it does not cover all the cases. I attached the test shell
script I used. Without the sleep & kill it does not die ...
The arguments patch or some other form of passing
arguments is essential
for using the policy-routing-script to redistribute routes from other
protocols...
As I said: Your idea is excellent - we just looked for an easy way to find a
suitable solution for all sort of cases. The latest revision (1066) contains
a method to forward the given arguments. You can use it like this:
batmand --policy-routing-script "test.sh one two three" eth0:bat
or even
batmand --policy-routing-script "test.sh \"one two three\"" eth0:bat
Greetings,
Marek
15 May
15 May
12:01 a.m.
On May 14, 2008, at 9:52 PM, Marek Lindner wrote:
This is because you use a "while true" loop.
Try instead:
while read bla
do
echo "bla: $bla"
done
Even simpler... Much better.
I created a new batquagga version (0.2) that does
exactly that and
even
when removing the "sleep" and "kill" commands from restore_defaults
(),
it works fine.
Unfortunately, it does not cover all the cases. I attached the test
shell
script I used. Without the sleep & kill it does not die ...
The arguments patch or some other form of passing
arguments is
essential
for using the policy-routing-script to redistribute routes from other
protocols...
As I said: Your idea is excellent - we just looked for an easy way
to find a
suitable solution for all sort of cases. The latest revision (1066)
contains
a method to forward the given arguments. You can use it like this:
batmand --policy-routing-script "test.sh one two three" eth0:bat
or even
batmand --policy-routing-script "test.sh \"one two three\"" eth0:bat
Greetings,
Marek
<test.sh>
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
2:12 a.m.
Hi,
This is because you use a "while true" loop.
I'm well aware of that. For you that might be enough but in general the
solution is not really perfect. I will get flooded with questions why batman
uses 100% cpu power. ;-)
What about sending a special "EXIT" command to give the child the possibility
to clean up. If the child is not dead after 10 seconds batman kills it.
Even simpler... Much better.
Yeah - I like it simple. Thanks for the idea and thanks Simon for input.
Greetings,
Marek
11 Jun
11 Jun
3:45 p.m.
On Wednesday, 14. May 2008 21:51:16 Antony Chazapis wrote:
I think that waiting and then killing the process is
not needed. If
you just
close the pipe, the other end should notice that there is an EOF at
stdin and die.
Ok, I applied your idea to the trunk and changed the demo script accordingly.
See revision 1080. Sending EXIT or something like that is even uglier ...
Greetings,
Marek
5405
days inactive
5440
days old
b.a.t.m.a.n@lists.open-mesh.org
18 comments
3 participants
participants (3)
-
Antony Chazapis -
Daniel Paufler -
Marek Lindner