public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Marek Lindner <lindner_marek@yahoo.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] 0.3 final <-> quagga
Date: Tue, 13 May 2008 16:34:19 +0800	[thread overview]
Message-ID: <200805131634.20052.lindner_marek@yahoo.de> (raw)
In-Reply-To: <CB4F1B6A-15D9-4CFD-BA29-4B6AC6F72596@cslab.ece.ntua.gr>


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.

  reply	other threads:[~2008-05-13  8:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-07 12:17 [B.A.T.M.A.N.] 0.3 final <-> quagga Antony Chazapis
2008-05-07 12:41 ` Marek Lindner
2008-05-07 13:00   ` Antony Chazapis
2008-05-07 13:29     ` Marek Lindner
2008-05-07 14:10       ` Antony Chazapis
2008-05-07 13:49 ` Daniel Paufler
2008-05-07 14:03   ` Marek Lindner
2008-05-07 16:17     ` Daniel Paufler
2008-05-08  9:23       ` Marek Lindner
2008-05-08  9:18         ` Daniel Paufler
2008-05-08 10:12           ` Marek Lindner
2008-05-12 22:26             ` Antony Chazapis
2008-05-13  8:34               ` Marek Lindner [this message]
2008-05-13  9:14                 ` Antony Chazapis
2008-05-14 13:51                   ` Antony Chazapis
2008-05-14 18:52                     ` Marek Lindner
2008-05-15  0:01                       ` Antony Chazapis
2008-05-15  2:12                         ` Marek Lindner
2008-06-11 15:45                     ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200805131634.20052.lindner_marek@yahoo.de \
    --to=lindner_marek@yahoo.de \
    --cc=b.a.t.m.a.n@open-mesh.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox