[B.A.T.M.A.N.] 0.3 final <-> quagga

[B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

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

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

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

On May 7, 2008, at 3:41 PM, Marek Lindner wrote:

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

I would prefer that you copy it over. I think it is better to keep  
things in one place. :)

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

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

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

> 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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Daniel Paufler]

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

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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

On May 7, 2008, at 4:29 PM, Marek Lindner wrote:

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

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.

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

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-script-argv.patch
into the main branch. It allow for passing args to the policy-routing- 
script, which is really useful.

Antony

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Daniel Paufler]

[-- Attachment #1.1: Type: text/plain, Size: 1325 bytes --]

Hey Marek

Marek Lindner wrote:
>> 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.
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



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Daniel Paufler]

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

Hello 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).
> 
> 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 ?
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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

> 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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

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@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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.

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

On May 13, 2008, at 11:34 AM, Marek Lindner wrote:

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

That's great. My apologies I couldn't find that before.

> 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@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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



> 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

[-- Attachment #2: test.sh --]
[-- Type: application/x-shellscript, Size: 262 bytes --]

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Antony Chazapis]

On May 14, 2008, at 9:52 PM, Marek Lindner wrote:

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

This is because you use a "while true" loop.

Try instead:

while read bla
do
      echo "bla: $bla"
done

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

Even simpler... Much better.

> Greetings,
> Marek
> <test.sh>
> _______________________________________________
> 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.] 0.3 final <-> quagga

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] 0.3 final <-> quagga

[Marek Lindner]

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