public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
* [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ?
@ 2009-11-25 10:58 Michael Rack
  2009-11-25 11:09 ` L. Aaron Kaplan
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Rack @ 2009-11-25 10:58 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

Dear List,

sorry if that is not the right place for my question. But the approach 
of B.A.T.M.A.N in how to choise the next hop is phantastic. Protocols 
how BGPv4 and OSPF only take the shortest path to the destination. 
B.A.T.M.A.N looks for the fastest way where the Hello-Message arrives first.

So long. I need a Routing-Protocol for static mash. My Wireless-Network 
besides on fixed Wireless Stations they become never to be dynamic. The 
complete Wireless Network is in Infrastructure-Mode. All members in the 
Network have just one role (AP / Client).

Currently OLSR does the routing job. But there lots of problems. OLSR 
also take the shortest path, also in case, a better link is available.

B.A.T.M.A.N is not suitable for my situation. The Client should not be 
able to select a desired gateway. A gateway should inject a default 
gateway to the clients, how OLSR does it.

Is there any other routing protocol on the market, that combine all that 
features, that i need?

     * Routing descission on fastest HelloMessage
     * Inject Default-Gateway via 0.0.0.0/0
     * Without tunneling data

I know. B.A.T.M.A.N is opensource. But i'm not familiar with C/C++ and 
so, i'm not able to do some modifications to the source.

Or is anyone out there, that can do the modification for me? Tell me, 
how long the work takes, and what you interested to earn for.

Requirements:

     * Disable the bat0 Interface
     * Enable announcing 0.0.0.0/0

Liebe Grüße aus Freilassing,

Michael Rack
RSM Freilassing
-- 
RSM Freilassing                 Tel.: +49 8654 607110
Nocksteinstr. 13                Fax.: +49 8654 670438
D-83395 Freilassing            www.rsm-freilassing.de


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ?
  2009-11-25 10:58 [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ? Michael Rack
@ 2009-11-25 11:09 ` L. Aaron Kaplan
  2009-11-25 13:58   ` elektra
  0 siblings, 1 reply; 5+ messages in thread
From: L. Aaron Kaplan @ 2009-11-25 11:09 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

Michael Rack wrote:
> Dear List,
>
> sorry if that is not the right place for my question. But the approach
> of B.A.T.M.A.N in how to choise the next hop is phantastic. Protocols
> how BGPv4 and OSPF only take the shortest path to the destination.
> B.A.T.M.A.N looks for the fastest way where the Hello-Message arrives
> first.
>
> So long. I need a Routing-Protocol for static mash. My
> Wireless-Network besides on fixed Wireless Stations they become never
> to be dynamic. The complete Wireless Network is in
> Infrastructure-Mode. All members in the Network have just one role (AP
> / Client).
>
> Currently OLSR does the routing job. But there lots of problems. OLSR
> also take the shortest path, also in case, a better link is available.
>
For OLSR development it would be interesting if you could discuss on the
mailing list there how your routing metric should be.
OLSR has a very nice framework (this is one of the advantages that it
has next tom some disadvantages) that actually you *can* change the metric!
We simply did not find any way yet to make layer 2 metrics cross
plattform comparable.

But this is better discussed on the OLSR mailing lists of course. (off
topic here)

> B.A.T.M.A.N is not suitable for my situation. The Client should not be
> able to select a desired gateway. A gateway should inject a default
> gateway to the clients, how OLSR does it.
>
> Is there any other routing protocol on the market, that combine all
> that features, that i need?
>

You could try BGP . It is for sure very stable and very well tested ;-)
And actually it is also used in static mesh networks.
I have the feeling that it will actually do what you want. without major
bugs.


>     * Routing descission on fastest HelloMessage
>     * Inject Default-Gateway via 0.0.0.0/0
>     * Without tunneling data
>
> Liebe Grüße aus Freilassing,
>
> Michael Rack
> RSM Freilassing


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ?
  2009-11-25 11:09 ` L. Aaron Kaplan
@ 2009-11-25 13:58   ` elektra
  2009-11-25 14:02     ` L. Aaron Kaplan
  0 siblings, 1 reply; 5+ messages in thread
From: elektra @ 2009-11-25 13:58 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

Hello Michael -


this question frequently pops up on this list.

You can use layer 3 Batman to announce a default route, but this is not 
recommended. Default routes in a large mesh are a pain in the ****. 
Which is something we quickly realized in the Freifunk community as soon 
as we had more than one gateway or malfunctioning gateways  - those will 
act as black holes and effectively interrupt your service.

You can circumvent the 0.0.0.0/0 check in Batman, by announcing two 
HNA's of 0.0.0.0/1 and 128.0.0.0/1 with the -a option. If you don't 
define a gateway class on the gateway the Batman gateway clients can't 
select a gateway.

Disadvantages: Other than the fact that I personally consider the 
announcement of 0.0.0.0/0 routes as sabotage - none that I know of, 
really. A few bytes overhead in the OGMs of the gateway, thats it.

We have occasional OLSR advertisement fade-ins on this list - I guess 
the Babel/OLSR/Batman quarrel will become proverbial one day ;-)

Cheers,
Elektra



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ?
  2009-11-25 13:58   ` elektra
@ 2009-11-25 14:02     ` L. Aaron Kaplan
  2009-11-25 14:49       ` [B.A.T.M.A.N.] Protocol quarrels elektra
  0 siblings, 1 reply; 5+ messages in thread
From: L. Aaron Kaplan @ 2009-11-25 14:02 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

Don't be unfair... Hang on, I actually said, OLSR stuff belongs on the respective mailing list there.
(and suggested to take a look at BGP)

> 
> We have occasional OLSR advertisement fade-ins on this list - I guess the Babel/OLSR/Batman quarrel will become proverbial one day ;-)





^ permalink raw reply	[flat|nested] 5+ messages in thread

* [B.A.T.M.A.N.] Protocol quarrels
  2009-11-25 14:02     ` L. Aaron Kaplan
@ 2009-11-25 14:49       ` elektra
  0 siblings, 0 replies; 5+ messages in thread
From: elektra @ 2009-11-25 14:49 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking



> Don't be unfair... Hang on, I actually said, OLSR stuff belongs on the respective mailing list there.
> (and suggested to take a look at BGP)
>
>   
>> We have occasional OLSR advertisement fade-ins on this list - I guess the Babel/OLSR/Batman quarrel will become proverbial one day ;-)
>>     

Methinks <http://www.dict.cc/englisch-deutsch/Methinks.html> thou 
<http://www.dict.cc/englisch-deutsch/thou.html> dost 
<http://www.dict.cc/englisch-deutsch/dost.html> protest 
<http://www.dict.cc/englisch-deutsch/protest.html> too 
<http://www.dict.cc/englisch-deutsch/too.html> much. 
<http://www.dict.cc/englisch-deutsch/much..html>

Read your own writing on the OLSR-users list below.

Cheers,
Elektra


[Olsr-users] Current OLSR protocol
L. Aaron Kaplan aaron at lo-res.org
 Fri May 22 14:29:52 UTC 2009
Previous message: [Olsr-users] Current OLSR protocol
Next message: [Olsr-users] Current OLSR protocol
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On May 22, 2009, at 3:46 PM, Damian Philipp wrote:

 > Hello,
 >
 > I'm currently gathering some information about available routing 
 > protocols for mesh networks for my diploma thesis. So far, I have 
 > found rather confusing things about OLSR. From 
http://www.olsr.org/?q=background
 >  I gathered that most of the optimizations to get olsr working were 
 > code improvements. However, 
https://www.open-mesh.org/wiki/the-olsr-story
 >  paints a somewhat different picture with inherent instabilities in 
 > the original concept of olsr which is why they started over with 
 > BATMAN.


Well... Let me give you my personal opinion on that.
Mainly Elektra from BATMAN was very often behind a FUD strategy 
against OLSR.
Which is weird but it is like that. Maybe it is in order to start the 
new project BATMAN.
 From the OLSR.org side, this is great that there is a new attempt at 
routing protocols since we can all learn from that and from the new 
problems that a new routing protocol will give in practice.

However, I would *not* take the-olsr-story on open-mesh.org as 
correct, final, authoritative nor complete.
Fact is that mesh research is an ongoing process and we can all simply 
learn.

 >
 > From what I've read on the freifunk homepage, olsr is still widely 
 > in use on freifunk networks.
it is.

 > I'm guessing that they are probably using the latest stable olsrd 
 > from olsr.org. However what I have not been able to find out is what 
 > protocol the current implementation from olsr.org is using. Is it 
 > still RCF-3626 compliant or does it rather contain all the 
 > optimizations from the C-Base people, thus breaking RFC compliance?
 >
it is RFC compliant but we all turn on extensions to RFC3626 in 
practice (ETX, Fisheye, ...) which break compatibility. But these are 
flags. You can turn them off.

 > As part of my thesis I will have to experiment with some extensions 
 > to the OLSR protocol. In order to be able to design those, I'd like 
 > to know the protocol I'm actually using ;-)
 >
  I suggest that you start to familiarize yourself with the basic 
datastructures, the RFC and maybe the plugin API. You will find more 
help concerning these issues on olsr-dev at lists.olsr.org.

 > I did find the OLSRv2-Draft at 
http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-08.txt
 > . This however still contains Multipoint relays, which as mentioned 
 > on open-mesh.org seem to be (have been?) one of the bigger issues -- 
 > thus my confusion.

no, ... open-mesh.org is a lot of personal opinion by Elektra.
So, again... take that with a grain of salt please ;-)

There was even once a paper published by Elektra and some insitute in 
South Africa which again "proves" that OLSR does not scale and stuff 
like that.

In the history of routing protocols you can always find this trend 
that some proposals were made, some succeeded in acceptance (i.e. they 
were made an RFC) and then a *great* deal* of work was still needed to 
actually make it scalable and secure in practice.

Take BGP for example: we (== the internet) is still fighting with some 
basic security problems of BGP [1]. So even the development of BGP is 
still ongoing.

Summary: it is the implementation which counts!
And OLSR.org put *a lot* of effort into that the last 2 years.

So the basic real dichotomy between OLSR.org and BATMAN is actually 
the question:
  "do something new or improve the old stuff?"
I guess both are valid positions somehow.


[1] http://www.wired.com/threatlevel/2008/08/revealed-the-in/




Previous message: [Olsr-users] Current OLSR protocol
Next message: [Olsr-users] Current OLSR protocol
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Olsr-users mailing list

[Olsr-users] Current OLSR protocol
L. Aaron Kaplan aaron at lo-res.org
 Fri May 22 15:51:00 UTC 2009
Previous message: [Olsr-users] Current OLSR protocol
Next message: [Olsr-users] Current OLSR protocol
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ulf, I do not agree with your assessment. The result of the FUD can be 
clearly seen by the uncertainty and doubt that people have been having 
repeatedly on this mailing list.
So therefore I believe I can rest my case and the mail by Damian was 
the proof for my FUD theory.

I also believe that I am actually quite fair. And I really do admire 
the work of Axel and others! No doubt about that!

:)

 >
 >
 > ps. it would be better to join to the wireless community weekend, to
 > work together on the olsr issues then writing such a crap!
 >

I am currently at work and could not come. Simple as that.

Besides, I do reserve the right to have my own experience and my 
opinion and do not tolerate others just calling my impression crap 
when they have no idea of *how* often I had to "defend" against the oh-
my-god-they-are-continuing-on-olsr.org-while-we-self-perceived-
semigods-in-berlin-are-already-working-on-batman-which-is-bettter-and-
therefore-the-rest-of-the-world-is-wrong-and-sucks attitude of some 
folks in Berlin. It is really tiresome to always have to "defend" a 
decision to still work on olsr.org in face of public *propaganda*.

I see it like that: there is room for improvement on olsr.org and 
there is a place for BATMAN.
Different goals. That is all. But why oh why do all the people get 
confused when they read Elektra's text on open-mesh.org ? Why do I see 
the same and the same type of questions again and again?
Exactly because it is propaganda.

ok, over and out. I think I made my point clear.
<joke>if you want we can carry this out in person with boxing gloves</
joke> ;-))


PS: again, in case it was not clear enough - congrats to successes of 
BATMAN . It is *not* the issue of which is better. It is an issue if 
Elektra pisses on other people constantly or not.
But I guess I should get simply used to that... seems like she likes 
it. *sigh*

whatever,
a.

 

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-11-25 14:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-25 10:58 [B.A.T.M.A.N.] What routingprotocol is similar to B.A.T.M.A.N ? Michael Rack
2009-11-25 11:09 ` L. Aaron Kaplan
2009-11-25 13:58   ` elektra
2009-11-25 14:02     ` L. Aaron Kaplan
2009-11-25 14:49       ` [B.A.T.M.A.N.] Protocol quarrels elektra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox