From (spam-protected)  Mon Feb  2 11:55:30 2009
From: (spam-protected) (Bernd Petrovitsch)
Date: Mon, 02 Feb 2009 11:55:30 +0100
Subject: [Olsr-users] compile error in olsrd-0.5.6-r3
In-Reply-To: <EE61EB01-3D12-48C7-AC4A-574B86CCE255@lo-res.org>
References: <be6635140901270919t33f87478k733e124f32566689@mail.gmail.com>
	<200901282106.44962.hrogge@googlemail.com>
	<1233261308.8073.8.camel@gimli.at.home>
	<200901292150.39352.hrogge@googlemail.com>
	<53b8f8fe0901291646r201e6572l3f9771a23ff63257@mail.gmail.com>
	<1233311311.5015.26.camel@spike.firmix.at>
	<53b8f8fe0901301544icc2403djfb5c4d343c0e9abf@mail.gmail.com>
	<EE61EB01-3D12-48C7-AC4A-574B86CCE255@lo-res.org>
Message-ID: <1233572130.24775.2.camel@spike.firmix.at>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090202/930c7a1c/attachment.ksh>

From (spam-protected)  Mon Feb  2 19:05:43 2009
From: (spam-protected) (Benjamin Henrion)
Date: Mon, 2 Feb 2009 19:05:43 +0100
Subject: [Olsr-users] OpenWRT HackNight at FOSDEM (Sat 7 Feb 2009, Brussels)
Message-ID: <20090202180543.GA1345@ffii.org>


=======================================================================
         OpenWRT HackNight at FOSDEM (Brussels, Sat 7th Feb)
=======================================================================

Hacker Space Brussels invites you to an OpenWRT HackNight this Saturday
of FOSDEM 7th Feb. OpenWRT is the best Linux distribution for embedded
devices.

The hacknight will be the oppurtunity to test the latest release RC2:
http://forum.openwrt.org/viewtopic.php?pid=80252#p80252

Many OpenWRT developers will be present at FOSDEM.

Date
====

Start: Saturday 07 Feb evening @ 18:00
End: Sunday 08 Feb @ 12:00

Goals
=====

 * Presentation of new features of RC2
 * Test of the RC2 on some Asus WL-HDD boxes, foneras, etc...
 * Drink belgian beers

We provide
==========

 * A fridge full of belgian Beers
 * space, electricty, internet
 * refreshments and snacks

Location
========

HackerSpace Brussels
Void*Pointer
Av princesse elisabeth 46
1030 Brussels
http://L45.be/where

Transport
=========

* Tram 23 from near ULB to our space (stop 'prinses elisabeth' is right
next our door).
* Nightbus Noctis stop 'verboekhoven' is a 100m walk.


Registration
============

Space is limited, so we ask you to register in advance by:

1. send an email to zoobab at gmail.com
AND
2. register on Doodle:
http://www.doodle.com/participation.html?pollId=4vzh6rrn92riqp85

Web
===

http://hsb.wikidot.com/openwrt-hacknight

Contact
=======

Benjamin Henrion <zoobab at gmail.com> +32-484-566109



From (spam-protected)  Tue Feb  3 08:25:05 2009
From: (spam-protected) (Bhat, Ishwara)
Date: Tue, 3 Feb 2009 12:55:05 +0530
Subject: [Olsr-users] Link Quality Fields
Message-ID: <1106299A6DFA0E4D8E13CFD83A7611F001BD3523@IE10EV813.global.ds.honeywell.com>

 

For OLSR's LQ, how many Hello packets are considered for link quality
calculation ? 

 

In windows build of OLSRd  (0.5.5) I saw that 'LinkQualityWinSize' is a
configuration parameter regarding this. In linux 0.5.6-r2, I did not
find anything similar.

 

However I found - LinkQualityAging in linux olsrd.conf.  How exactly is
this used ?  

 

Is there any other field which influence LQ/NLQ and ETX ?

 

 

Thanks

Ishwar

"This e-mail, and any attachments thereto, are intended only for use by
the addressee(s) named herein and may contain privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is illegal and
strictly prohibited. If you have received this e-mail in error, please
immediately notify me by telephone and permanently delete the original
and any copy of any e-mail and any printout thereof."

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090203/65ec6c91/attachment.html>

From (spam-protected)  Tue Feb  3 09:29:13 2009
From: (spam-protected) (Henning Rogge)
Date: Tue, 3 Feb 2009 09:29:13 +0100
Subject: [Olsr-users] Link Quality Fields
In-Reply-To: <1106299A6DFA0E4D8E13CFD83A7611F001BD3523@IE10EV813.global.ds.honeywell.com>
References: <1106299A6DFA0E4D8E13CFD83A7611F001BD3523@IE10EV813.global.ds.honeywell.com>
Message-ID: <200902030929.14079.rogge@fgan.de>

Am Tuesday 03 February 2009 08:25:05 schrieb Bhat, Ishwara:
> For OLSR's LQ, how many Hello packets are considered for link quality
> calculation ?
Depends on the LQ algorithm you use.

etx_float and etx_fpm use an exponential moving average, so they consider an 
"infinite amount of hellos".
etx_ff considers all OLSR packages (not only hellos) within the last 16 
seconds.

> In windows build of OLSRd  (0.5.5) I saw that 'LinkQualityWinSize' is a
> configuration parameter regarding this. In linux 0.5.6-r2, I did not
> find anything similar.
Yes, window size is gone... it's no longer usable because we changed the LQ 
algorithm.

> However I found - LinkQualityAging in linux olsrd.conf.  How exactly is
> this used ?
LQaging is the aging parameter of the exp. moving average for etx_fpm and 
etx_float.

(the next version of OLSR will move all LQ algorithms into real plugins, so 
each of them can have parameters of it's own).

etx_ff does not have any parameters.

> Is there any other field which influence LQ/NLQ and ETX ?
There is the "lq multiplier" parameter, but most times you should keep it on 
"1".

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090203/f54f5e73/attachment.sig>

From (spam-protected)  Tue Feb  3 09:53:09 2009
From: (spam-protected) (Bhat, Ishwara)
Date: Tue, 3 Feb 2009 14:23:09 +0530
Subject: [Olsr-users] Link Quality Fields
In-Reply-To: <200902030929.14079.rogge@fgan.de>
References: <1106299A6DFA0E4D8E13CFD83A7611F001BD3523@IE10EV813.global.ds.honeywell.com>
	<200902030929.14079.rogge@fgan.de>
Message-ID: <1106299A6DFA0E4D8E13CFD83A7611F001BD3635@IE10EV813.global.ds.honeywell.com>

Thanks a lot.

Please tell if there is any reason for fixing etx_ff's window to 16 second. 

Can't this be configurable? 

For instance when we use OLSR for control applications involving mobile sensors, such field would be very useful. Different sensor networks have different field topology & scenarios, response time etc.
In such applications flexibility with link decision greatly helps.


And with etc_fpm, what is the purpose of averaging from infinite Hellos ? I thought this helps only if mobility is low. But applications where each node is highly mobile, then considering say 2 minute old hellos would not be appropriate..?


Thanks,
Ishwar

-----Original Message-----
From: olsr-users-bounces at lists.olsr.org [mailto:olsr-users-bounces at lists.olsr.org] On Behalf Of Henning Rogge
Sent: Tuesday, February 03, 2009 1:59 PM
To: olsr-users at lists.olsr.org
Subject: Re: [Olsr-users] Link Quality Fields

Am Tuesday 03 February 2009 08:25:05 schrieb Bhat, Ishwara:
> For OLSR's LQ, how many Hello packets are considered for link quality
> calculation ?
Depends on the LQ algorithm you use.

etx_float and etx_fpm use an exponential moving average, so they consider an 
"infinite amount of hellos".
etx_ff considers all OLSR packages (not only hellos) within the last 16 
seconds.

> In windows build of OLSRd  (0.5.5) I saw that 'LinkQualityWinSize' is a
> configuration parameter regarding this. In linux 0.5.6-r2, I did not
> find anything similar.
Yes, window size is gone... it's no longer usable because we changed the LQ 
algorithm.

> However I found - LinkQualityAging in linux olsrd.conf.  How exactly is
> this used ?
LQaging is the aging parameter of the exp. moving average for etx_fpm and 
etx_float.

(the next version of OLSR will move all LQ algorithms into real plugins, so 
each of them can have parameters of it's own).

etx_ff does not have any parameters.

> Is there any other field which influence LQ/NLQ and ETX ?
There is the "lq multiplier" parameter, but most times you should keep it on 
"1".

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)




From (spam-protected)  Tue Feb  3 10:04:38 2009
From: (spam-protected) (Henning Rogge)
Date: Tue, 3 Feb 2009 10:04:38 +0100
Subject: [Olsr-users] Link Quality Fields
In-Reply-To: <1106299A6DFA0E4D8E13CFD83A7611F001BD3635@IE10EV813.global.ds.honeywell.com>
References: <1106299A6DFA0E4D8E13CFD83A7611F001BD3523@IE10EV813.global.ds.honeywell.com>
	<200902030929.14079.rogge@fgan.de>
	<1106299A6DFA0E4D8E13CFD83A7611F001BD3635@IE10EV813.global.ds.honeywell.com>
Message-ID: <200902031004.43762.rogge@fgan.de>

Am Tuesday 03 February 2009 09:53:09 schrieb Bhat, Ishwara:
> Thanks a lot.
>
> Please tell if there is any reason for fixing etx_ff's window to 16 second.
Because I thought it would be a good value to test the new metric.

> Can't this be configurable?
Yes, it could be made configurable. But when I wrote etx_ff there was no way 
to have parameters for each of the link metrics (except creating new global 
parameters). So the 0.5.7 version of etx_ff might get a configuration option 
for this.

> For instance when we use OLSR for control applications involving mobile
> sensors, such field would be very useful. Different sensor networks have
> different field topology & scenarios, response time etc. In such
> applications flexibility with link decision greatly helps.
Yes.

> And with etc_fpm, what is the purpose of averaging from infinite Hellos ? I
> thought this helps only if mobility is low. But applications where each
> node is highly mobile, then considering say 2 minute old hellos would not
> be appropriate..?
http://en.wikipedia.org/wiki/Exponential_moving_average#Exponential_moving_average

It's not just an "average" over an infinite hello intervals.

Henning


*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090203/846126a5/attachment.sig>

From (spam-protected)  Tue Feb  3 14:01:38 2009
From: (spam-protected) (ZioPRoTo (Saverio Proto))
Date: Tue, 3 Feb 2009 14:01:38 +0100
Subject: [Olsr-users] Using different LQ algorithms
Message-ID: <a5e23ab90902030501q382a48d1h5877f5e26ccf48a1@mail.gmail.com>

> Depends on the LQ algorithm you use.
>
> etx_float and etx_fpm use an exponential moving average, so they consider an
> "infinite amount of hellos".
> etx_ff considers all OLSR packages (not only hellos) within the last 16
> seconds.

Ehm ... I read this email and I got pretty scared :)

At Ninux.org we have some tens of nodes speaking OLSR, all with
different versions. From 0.4.x going on up up to the latest shipped
with the trunk of OpenWRT.

Last weekend I went to install a new node, and OLSR was acting really
funny with a neighbor node that was shipping and older OLSR version.

At this point my question is:

I always believed that different versions of OLSR where supposed to
work consistently, but now that different algorithm are implemented,
are different version still compatible ?? What is the default
algorithm assuming standard config file ?

Saverio



From (spam-protected)  Tue Feb  3 14:11:10 2009
From: (spam-protected) (Henning Rogge)
Date: Tue, 3 Feb 2009 14:11:10 +0100
Subject: [Olsr-users] Using different LQ algorithms
In-Reply-To: <a5e23ab90902030501q382a48d1h5877f5e26ccf48a1@mail.gmail.com>
References: <a5e23ab90902030501q382a48d1h5877f5e26ccf48a1@mail.gmail.com>
Message-ID: <200902031411.15486.rogge@fgan.de>

Am Tuesday 03 February 2009 14:01:38 schrieb ZioPRoTo (Saverio Proto):
> > Depends on the LQ algorithm you use.
> >
> > etx_float and etx_fpm use an exponential moving average, so they consider
> > an "infinite amount of hellos".
> > etx_ff considers all OLSR packages (not only hellos) within the last 16
> > seconds.
>
> Ehm ... I read this email and I got pretty scared :)
No need to be scared.

> At Ninux.org we have some tens of nodes speaking OLSR, all with
> different versions. From 0.4.x going on up up to the latest shipped
> with the trunk of OpenWRT.
>
> Last weekend I went to install a new node, and OLSR was acting really
> funny with a neighbor node that was shipping and older OLSR version.
There are a few bugs in the old (pre 0.5.6 olsr) ETX logic, so I would not be 
surprised to see strange results with old versions.

> At this point my question is:
>
> I always believed that different versions of OLSR where supposed to
> work consistently, but now that different algorithm are implemented,
> are different version still compatible ??
all three algorithms calculate the same ETX value. The problem is that the old 
OLSR implementation has a REALLY bad scheduler, so the hello timeouts are not 
okay (sometimes hello packages come more than 50% too late).

So you might see strange results.

etx_ff should do better with old olsr versions I think.

> What is the default
> algorithm assuming standard config file ?
etx_fpm for 0.5.6, etx_ff for the development tree.

Oh, the next mayor update (most likely 0.6.0 or 1.0.0, not 0.5.7) will have 
additional link layer aware metrics that will be DEFINITELY incompatible with 
the old ETX value... but they won't be activated as a default metric.

They will be not in 0.5.7 because we need time to test the new linklayer aware 
metric system. But there will be an OLSR version in the future with real ETT 
support.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090203/d606a71e/attachment.sig>

From (spam-protected)  Wed Feb  4 00:41:13 2009
From: (spam-protected) (Juliusz Chroboczek)
Date: Wed, 04 Feb 2009 00:41:13 +0100
Subject: [Olsr-users] PKI architecture for freifunk/funkfeier
In-Reply-To: <200901301056.28397.rogge@fgan.de> (Henning Rogge's message of
	"Fri\, 30 Jan 2009 10\:56\:21 +0100")
References: <4367.85.41.146.93.1232124059.squirrel@krisma.oltrelinux.com>
	<7iwscf46wo.fsf_-_@lanthane.pps.jussieu.fr>
	<200901291919.48920.hrogge@googlemail.com>
	<200901301056.28397.rogge@fgan.de>
Message-ID: <7iiqnrccme.fsf@lanthane.pps.jussieu.fr>

> Theoretically we could just set up a central PKI (which would make things
> very easy), but this would allow the owner/maintainer of the PKI to
> control the whole network. This is not acceptable for a community project
> like Freifunk and Funkfeuer.

Yep.  Additionally, as others have mentioned, you don't want to perform
asymmetric crypto on every routing packet.

> My idea is that each gateway to the internet set up it's own PKI root
> key. The owners of the gateways can build something like a web of trust
> between each other.

A simpler solution would be for each node to have a list of trusted keys
(stored as a file somewhere in the filesystem).  Your node would
periodically (say, once every night) download a PGP-signed list of trusted
keys.

Friendly people could then provide lists of public keys of trusted
gateways.  For example, I could program my node to download the list
provided by Henning and the list provided by Aaron, merge the two, then
remove key 77FF5F3B, which happens to belong to somebody I don't trust.

The main advantage is that all of the complex policy issues are cleanly
encapsulated in the downloading process -- the routing daemon only checks
the packets against a list of keys.  The main flaw is that it means that
a new gateway cannot fully join the network in less than 24 hours.

I'm sure there are hashing schemes that are cheap enough for your average
200MHz MIPS chip.

                                        Juliusz



From (spam-protected)  Wed Feb  4 00:49:23 2009
From: (spam-protected) (Juliusz Chroboczek)
Date: Wed, 04 Feb 2009 00:49:23 +0100
Subject: [Olsr-users] Multihoming the mesh [was: PKI architecture...]
In-Reply-To: <1233319138.5015.46.camel@spike.firmix.at> (Bernd Petrovitsch's
	message of "Fri\, 30 Jan 2009 13\:38\:58 +0100")
References: <4367.85.41.146.93.1232124059.squirrel@krisma.oltrelinux.com>
	<200901301142.08399.rogge@fgan.de>
	<1233313343.5015.33.camel@spike.firmix.at>
	<200901301302.26804.rogge@fgan.de>
	<1233319138.5015.46.camel@spike.firmix.at>
Message-ID: <7ieiyfcc8s.fsf_-_@lanthane.pps.jussieu.fr>

>> > Assume a network using public IPs: I don't think that a random ISP
>> > customer (as seen from the ISP) has success in getting the ISP to speak
>> > BGPv4 with him.

> The problem is: Even if I want to make a gateway for FunkFeuer at my
> home, I plain simply can't.

Yes.  What you're saying is that there isn't a way to multihome an IP
network unless you have an upstream that (1) allows you to advertise random
BGP routes and (2) doesn't do uRPF.

This issue is not specific to mesh networks -- in my opinion, it's the one
most unsatisfying thing about IP.

                                        Juliusz





From (spam-protected)  Wed Feb  4 01:01:39 2009
From: (spam-protected) (Juliusz Chroboczek)
Date: Wed, 04 Feb 2009 01:01:39 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	(Benjamin Henrion's message of "Fri\,
	23 Jan 2009 11\:44\:11 +0100")
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
Message-ID: <7i63jrcboc.fsf@lanthane.pps.jussieu.fr>

> Does someone has already tried this:
>
> http://www.pps.jussieu.fr/~jch/software/ahcp/

As far as I know, it's only us in Paris using AHCP.

The current AHCP protocol is overly complicated, and I've learned a few new
tricks since I first developed it.  I'm currently working on a new revision
of the protocol, which I hope I'll be able to make public soon.

                                        Juliusz



From (spam-protected)  Wed Feb  4 19:08:47 2009
From: (spam-protected) (Breno Jacinto)
Date: Wed, 4 Feb 2009 15:08:47 -0300
Subject: [Olsr-users] Compatible network adapters for ad hoc networking
Message-ID: <2ced936d0902041008yf3aba9fn3fc77acfb6e54aeb@mail.gmail.com>

Hello everyone,

  I`m running several experiments involving ad hoc networks. I`ve
selected some well known-to-be-compatible adapters, such as Edimax
(Ralink shipset), Alfa networks (Realtek) and Atheros (madwifi).
Atheros is available only as built-in adapter on the equipement or as
a  PCI board.

  So, I'm experiencing some instability regarding the selection of
the BSSID used by all the nodes. I start the network with a single
node, then another, then another. Now, for a couple of minutes it
works, bu then some nodes start losing sight of each and changing
their BSSIDs to a different value (when they should be in sync). I'm
really running out of
explanations of why this is happening, because these nodes are all
in-range of each other, and should be "pingable" directly. My main
suspect is the driver instability, but then I dont know of any other
better alternatives. I've tested the following USB adapters:

- Edimax EW-7318USg (rt73 drivers)
- Alfa AWUS036H-11g

  And the builtin adapters:

- Atheros chipset AR5007EG


best regards,

-- 
-- 
:: Breno Jacinto ::
:: breno - at - gprt.ufpe.br ::
:: FingerPrint ::
   2F15 8A61 F566 E442 8581
   E3C0 EFF4 E202 74B7 7484
:: Persistir no difícil é a única maneira de torná-lo fácil algum dia.  ::



From (spam-protected)  Thu Feb  5 11:49:51 2009
From: (spam-protected) (Bernd Petrovitsch)
Date: Thu, 05 Feb 2009 11:49:51 +0100
Subject: [Olsr-users] Multihoming the mesh
In-Reply-To: <7ieiyfcc8s.fsf_-_@lanthane.pps.jussieu.fr>
References: <4367.85.41.146.93.1232124059.squirrel@krisma.oltrelinux.com>
	<200901301142.08399.rogge@fgan.de>
	<1233313343.5015.33.camel@spike.firmix.at>
	<200901301302.26804.rogge@fgan.de>
	<1233319138.5015.46.camel@spike.firmix.at>
	<7ieiyfcc8s.fsf_-_@lanthane.pps.jussieu.fr>
Message-ID: <1233830991.27911.28.camel@spike.firmix.at>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090205/b7189bb2/attachment.ksh>

From (spam-protected)  Thu Feb  5 17:39:41 2009
From: (spam-protected) (joseph regan)
Date: Thu, 5 Feb 2009 17:39:41 +0100
Subject: [Olsr-users] Mesh for Humanitarian Aid
Message-ID: <66049ddb0902050839i5dc6346cjd91d88a81e9c041a@mail.gmail.com>

Help!  I am trying to set up a wireless mesh network for a humanitarian
organization.  This mesh will be used for emergencies across the world, if
there is a disaster and their communications go out, we provide phone and
internet.  The mesh will be great to provide satellite internet meshed.

So far, I have downloaded and installed OpenWRT on two RB133s.  These units
have two wireless cards and 3 ethernet ports.  We'd like a 5 GHz backhaul
and deliver the internet on a standard 2.4 GHz channel.  I have installed
OLSR and configured it fine.  When I connect to a RB133 wirelessly, and I
have a ethernet cord in that board, it works no problem.  However, when I
test out the meshing capability, and I try to connect to a RB133 without the
ethernet cord, I cannot get any internet.  Any help would be greatly
appreciated!  Below are my configuration ports.  Anyone who can provide any
help whatsoever will be able to help make a change in the world!

OLSRD.CONF
(everything is standard, short of changing one line)
changed line:

Interface "ath1" "ath0" "eth0" "wifi0" "wifi1"

------------------------------------------------------------------------------------------------------
/ETC/CONFIG/NETWORK

config 'interface'
'loopback'

        option 'ifname'
'lo'

        option 'proto'
'static'

        option 'ipaddr'
'127.0.0.1'

        option 'netmask'
'255.0.0.0'



config 'interface'
'lan'

        option 'ifname'
'eth0'

        option 'type'
'bridge'

        option 'proto'
'static'

        option 'netmask'
'255.255.255.0'

        option 'macaddr'
''

        option 'ipaddr'
'192.168.0.248'

        option 'ip6addr'
''

        option 'gateway'
'192.168.0.254'

        option 'ip6gw'
''

        option 'dns' '
192.168.0.1'



config 'interface'
'wlan'

        option 'ifname'
'wifi1'

        option 'proto'
'static'

        option 'ipaddr'
'10.0.0.2'

        option 'netmask'
'255.255.255.0'

        option 'macaddr'
''

        option 'ip6addr'
''

        option 'gateway'
''

        option 'ip6gw' ''
----------------------------------------------------------------------------------------
/ETC/CONFIG/WIRELESS
config 'wifi-device' 'wifi0'
        option 'type' 'atheros'

        option 'hwmode' '11bg'
        option 'maxassoc' ''
        option 'distance' ''
        option 'disabled' '0'
        option 'antenna' ''
        option 'channel' '06'
        option 'diversity' '0'
        option 'txantenna' '1'
        option 'rxantenna' '1'

config 'wifi-iface'
        option 'device' 'wifi0'
        option 'network' 'lan'
        option 'mode' 'ap'
        option 'encryption' 'none'
        option 'bssid' ''
        option 'server' ''
        option 'port' ''
        option 'hidden' '0'
        option 'isolate' '0'
        option 'bgscan' '0'
        option 'frag' ''
        option 'rts' ''
        option 'key1' ''
        option 'key2' ''
        option 'key3' ''
        option 'key4' ''
        option '80211h' '0'
        option 'compression' ''
        option 'bursting' '0'
        option 'ff' ''
        option 'wmm' '0'
        option 'xr' ''
        option 'ar' ''
        option 'turbo' ''
        option 'macpolicy' 'none'
        option 'maclist' ''
        option 'ssid' 'OpenWrt2'
        option 'txpower' '4'

config 'wifi-device' 'wifi1'
        option 'type' 'atheros'

        option 'agmode' '11a'
        option 'maxassoc' ''
        option 'distance' ''
        option 'disabled' '0'
        option 'antenna' ''
        option 'channel' '36'
        option 'diversity' '0'
        option 'txantenna' '1'
        option 'rxantenna' '1'

config 'wifi-iface'
        option 'device' 'wifi1'
        option 'encryption' 'none'
        option 'ssid' 'tsfmesh'
        option 'bssid' ''
        option 'server' ''
        option 'port' ''
        option 'hidden' '0'
        option 'isolate' '0'
        option 'bgscan' '0'
        option 'frag' ''
        option 'rts' ''

        option 'key1' ''
        option 'key2' ''
        option 'key3' ''
        option 'key4' ''
        option '80211h' ''
        option 'compression' ''
        option 'bursting' ''
        option 'ff' ''
        option 'wmm' ''
        option 'xr' ''
        option 'ar' ''
        option 'turbo' ''
        option 'macpolicy' 'none'
        option 'maclist' ''
        option 'maclist' ''
        option 'network' 'wlan'
        option 'mode' 'adhoc'
        option 'txpower' '4'


Im not too sure how to configure DHCP, not sure if I need to configure it
(or anything else)
Any advice would be extremely appreciated!



-- 

Joseph Regan

Senator of Computer Engineering
NJIT
http://studentsenate.njit.edu

Owner
Shore Computer Company
Point Pleasant, NJ 08742
http://www.shorecc.tk
tel: 732-295-7007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090205/ccdced4e/attachment.html>

From (spam-protected)  Thu Feb  5 23:49:38 2009
From: (spam-protected) (Kim Hawtin)
Date: Fri, 06 Feb 2009 09:19:38 +1030
Subject: [Olsr-users] Mesh for Humanitarian Aid
In-Reply-To: <66049ddb0902050839i5dc6346cjd91d88a81e9c041a@mail.gmail.com>
References: <66049ddb0902050839i5dc6346cjd91d88a81e9c041a@mail.gmail.com>
Message-ID: <498B6D02.5000607@adelaide.edu.au>

Hi Joseph,

joseph regan wrote:
> Help!  I am trying to set up a wireless mesh network for a humanitarian
> organization.  This mesh will be used for emergencies across the world, if
> there is a disaster and their communications go out, we provide phone and
> internet.  The mesh will be great to provide satellite internet meshed.
> 
> So far, I have downloaded and installed OpenWRT on two RB133s.  These units
> have two wireless cards and 3 ethernet ports.  We'd like a 5 GHz backhaul
> and deliver the internet on a standard 2.4 GHz channel.  I have installed
> OLSR and configured it fine.  When I connect to a RB133 wirelessly, and I
> have a ethernet cord in that board, it works no problem.  However, when I
> test out the meshing capability, and I try to connect to a RB133 without the
> ethernet cord, I cannot get any internet.  Any help would be greatly
> appreciated!  Below are my configuration ports.  Anyone who can provide any
> help whatsoever will be able to help make a change in the world!

I notice that you are bridging the lan to wifi0. Is this what you really want?

Perhaps you may prefer setting up each ethernet interface with its own subnet
and routing them all. This may require you to announce HNA routes. Thats how I
do it, but I am sure that others may have better suggestions. =)

I've found that bridging and routing on the same host don't always mix nicely.

> OLSRD.CONF
> (everything is standard, short of changing one line)
> changed line:
> 
> Interface "ath1" "ath0" "eth0" "wifi0" "wifi1"
> 
> ------------------------------------------------------------------------------------------------------
> /ETC/CONFIG/NETWORK
> 
> config 'interface' 'loopback'
>         option 'ifname' 'lo'
>         option 'proto' 'static'
>         option 'ipaddr' '127.0.0.1'
>         option 'netmask' '255.0.0.0'
>
> config 'interface' 'lan'
>         option 'ifname' 'eth0'
>         option 'type' 'bridge'
>         option 'proto' 'static'
>         option 'netmask' '255.255.255.0'
>         option 'macaddr' ''
>         option 'ipaddr' '192.168.0.248'
>         option 'ip6addr' ''
>         option 'gateway' '192.168.0.254'
>         option 'ip6gw' ''
>         option 'dns' ' 192.168.0.1'
> 
> config 'interface' 'wlan'
>         option 'ifname' 'wifi1'
>         option 'proto' 'static'
>         option 'ipaddr' '10.0.0.2'
>         option 'netmask' '255.255.255.0'
>         option 'macaddr' ''
>         option 'ip6addr' ''
>         option 'gateway' ''
>         option 'ip6gw' ''
> ----------------------------------------------------------------------------------------
> /ETC/CONFIG/WIRELESS
> config 'wifi-device' 'wifi0'
>         option 'type' 'atheros'
> 
>         option 'hwmode' '11bg'
>         option 'maxassoc' ''
>         option 'distance' ''
>         option 'disabled' '0'
>         option 'antenna' ''
>         option 'channel' '06'
>         option 'diversity' '0'
>         option 'txantenna' '1'
>         option 'rxantenna' '1'
> 
> config 'wifi-iface'
>         option 'device' 'wifi0'
>         option 'network' 'lan'
>         option 'mode' 'ap'
>         option 'encryption' 'none'
>         option 'bssid' ''
>         option 'server' ''
>         option 'port' ''
>         option 'hidden' '0'
>         option 'isolate' '0'
>         option 'bgscan' '0'
>         option 'frag' ''
>         option 'rts' ''
>         option 'key1' ''
>         option 'key2' ''
>         option 'key3' ''
>         option 'key4' ''
>         option '80211h' '0'
>         option 'compression' ''
>         option 'bursting' '0'
>         option 'ff' ''
>         option 'wmm' '0'
>         option 'xr' ''
>         option 'ar' ''
>         option 'turbo' ''
>         option 'macpolicy' 'none'
>         option 'maclist' ''
>         option 'ssid' 'OpenWrt2'
>         option 'txpower' '4'
> 
> config 'wifi-device' 'wifi1'
>         option 'type' 'atheros'
> 
>         option 'agmode' '11a'
>         option 'maxassoc' ''
>         option 'distance' ''
>         option 'disabled' '0'
>         option 'antenna' ''
>         option 'channel' '36'
>         option 'diversity' '0'
>         option 'txantenna' '1'
>         option 'rxantenna' '1'
> 
> config 'wifi-iface'
>         option 'device' 'wifi1'
>         option 'encryption' 'none'
>         option 'ssid' 'tsfmesh'
>         option 'bssid' ''
>         option 'server' ''
>         option 'port' ''
>         option 'hidden' '0'
>         option 'isolate' '0'
>         option 'bgscan' '0'
>         option 'frag' ''
>         option 'rts' ''
>         option 'key1' ''
>         option 'key2' ''
>         option 'key3' ''
>         option 'key4' ''
>         option '80211h' ''

whats this one?   ^^^^^^ h?

>         option 'compression' ''
>         option 'bursting' ''
>         option 'ff' ''
>         option 'wmm' ''
>         option 'xr' ''
>         option 'ar' ''
>         option 'turbo' ''
>         option 'macpolicy' 'none'
>         option 'maclist' ''
>         option 'maclist' ''
>         option 'network' 'wlan'
>         option 'mode' 'adhoc'
>         option 'txpower' '4'

so do you need to set all these to nothing?
i usually comment them out if i'm not using them.

> Im not too sure how to configure DHCP, not sure if I need to configure it
> (or anything else)
> Any advice would be extremely appreciated!

More info on dnsmasq can be found here;
http://wiki.openwrt.org/OpenWrtDocs/KamikazeConfiguration

regards,

kim
-- 
Operating Systems, Services and Operations
Information Technology Services, The University of Adelaide
kim.hawtin at adelaide.edu.au



From (spam-protected)  Sun Feb  8 10:53:54 2009
From: (spam-protected) (Henning Rogge)
Date: Sun, 8 Feb 2009 10:53:54 +0100
Subject: [Olsr-users] PKI architecture for freifunk/funkfeier
In-Reply-To: <7iiqnrccme.fsf@lanthane.pps.jussieu.fr>
References: <4367.85.41.146.93.1232124059.squirrel@krisma.oltrelinux.com>
	<200901301056.28397.rogge@fgan.de>
	<7iiqnrccme.fsf@lanthane.pps.jussieu.fr>
Message-ID: <200902081053.59643.hrogge@googlemail.com>

On Mittwoch 04 Februar 2009 00:41:13 Juliusz Chroboczek wrote:
> > Theoretically we could just set up a central PKI (which would make things
> > very easy), but this would allow the owner/maintainer of the PKI to
> > control the whole network. This is not acceptable for a community project
> > like Freifunk and Funkfeuer.
>
> Yep.  Additionally, as others have mentioned, you don't want to perform
> asymmetric crypto on every routing packet.
Okay...

> > My idea is that each gateway to the internet set up it's own PKI root
> > key. The owners of the gateways can build something like a web of trust
> > between each other.
>
> A simpler solution would be for each node to have a list of trusted keys
> (stored as a file somewhere in the filesystem).  Your node would
> periodically (say, once every night) download a PGP-signed list of trusted
> keys.
Yes, that should be always the first step. The user of a node has to choose a 
"source" where he get's his master key(s). Or multiple sources...

> Friendly people could then provide lists of public keys of trusted
> gateways.  For example, I could program my node to download the list
> provided by Henning and the list provided by Aaron, merge the two, then
> remove key 77FF5F3B, which happens to belong to somebody I don't trust.
Yes, that would be a nice way to do it...

the routing agent stores a number of sources for trusted keys (most likely in 
form of signed certificates, so you can cache and redistribute them) and 
updates them once every 24 hours. In a meshnet it might be even better to push 
them from the servers to the network once every 24 hours with a netwide 
broadcast, but that's just an optimization.

> The main advantage is that all of the complex policy issues are cleanly
> encapsulated in the downloading process -- the routing daemon only checks
> the packets against a list of keys.
The question is HOW to check them... if you just use a cryptographic hash and 
a symmetric encryption function, anyone who has to check the package needs the 
symmetric key, so he can forge packages.

> The main flaw is that it means that
> a new gateway cannot fully join the network in less than 24 hours.
Maybe it's a good thing to "generalize" the idea of "multiple PKI roots" away 
from the gateways. A Freifunk/Funkfeuer/Community-Mesh network might just 
choose to have "n" PKI servers which are maintained by different trusted 
people. The sum of this servers should be used to handle authentification in 
the network, so you have both some redundancy (one/two keyservers down) and 
security against a mean admin.

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090208/76ed5a5d/attachment.sig>

From (spam-protected)  Mon Feb  9 11:45:44 2009
From: (spam-protected) (ZioPRoTo (Saverio Proto))
Date: Mon, 9 Feb 2009 11:45:44 +0100
Subject: [Olsr-users] [Olsr-dev] Good ideas about interface IPs in OLSR
In-Reply-To: <200902051738.56672.hrogge@googlemail.com>
References: <200902051738.56672.hrogge@googlemail.com>
Message-ID: <a5e23ab90902090245n4f644de5s1bd30eb558a299f1@mail.gmail.com>

> The "ethernet" settings tells OLSR that this interface has no real loss on
> it's broadcast domain (either anyone gets it or noone gets it), so it does not
> need to retransmit OLSR packages received from this interface back into the
> interface again.

Maybe it also makes sense to put a default ETX value (say 1) for
ethernet links, because there is suppose to be no packet loss on them.

> Another part of the puzzle is the idea to set the source address of all routes
> to the main IP. This way any package created on the router will have the main-
> IP of the router as the source field. It needs some additional work, but
> Markus Kittenberg is already working on it.

Mmm... this removes the need for MID messages ? :)

> In the end (which might be a year away or more) it would be nice to reduce the
> importance of the interface IPs even more, so that we can switch to link-local
> (autoconfigured !) addresses in IPv6.

Just keep in mind that IP packets with a IPv6 link-local destination
are not forwarded by routers.

Saverio



From (spam-protected)  Mon Feb  9 12:49:29 2009
From: (spam-protected) (Henning Rogge)
Date: Mon, 9 Feb 2009 12:49:29 +0100
Subject: [Olsr-users] [Olsr-dev] Good ideas about interface IPs in OLSR
In-Reply-To: <a5e23ab90902090245n4f644de5s1bd30eb558a299f1@mail.gmail.com>
References: <200902051738.56672.hrogge@googlemail.com>
	<a5e23ab90902090245n4f644de5s1bd30eb558a299f1@mail.gmail.com>
Message-ID: <200902091249.29797.rogge@fgan.de>

Am Monday 09 February 2009 11:45:44 schrieb ZioPRoTo (Saverio Proto):
> > The "ethernet" settings tells OLSR that this interface has no real loss
> > on it's broadcast domain (either anyone gets it or noone gets it), so it
> > does not need to retransmit OLSR packages received from this interface
> > back into the interface again.
>
> Maybe it also makes sense to put a default ETX value (say 1) for
> ethernet links, because there is suppose to be no packet loss on them.
We might do this and just use the Hello protocoll to handle automatic 
detection of "virtual neighbors" which have to combine their resources.

> > Another part of the puzzle is the idea to set the source address of all
> > routes to the main IP. This way any package created on the router will
> > have the main- IP of the router as the source field. It needs some
> > additional work, but Markus Kittenberg is already working on it.
>
> Mmm... this removes the need for MID messages ? :)
Might be. I'm not completely sure about it, but I think we could keep the MID 
information on hello (1-hop) level.

> > In the end (which might be a year away or more) it would be nice to
> > reduce the importance of the interface IPs even more, so that we can
> > switch to link-local (autoconfigured !) addresses in IPv6.
>
> Just keep in mind that IP packets with a IPv6 link-local destination
> are not forwarded by routers.
Only the gateway address of each route will be link-local. The destination 
will always be
- either a router-id (originator address) of a MANET node
- or an address behind a HNA-attached network

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090209/e807b8b5/attachment.sig>

From (spam-protected)  Mon Feb  9 18:21:47 2009
From: (spam-protected) ((spam-protected))
Date: Mon, 9 Feb 2009 11:21:47 -0600
Subject: [Olsr-users] No neighbor routes in 0.5.4
Message-ID: <OFAAD765A0.5C167C24-ON86257558.005CB8B0-86257558.005F60FE@rockwellcollins.com>

I am running the 0.5.4 version in a two node network with TC_REDUNDANCY 
set to 0 to reduce the amount of TC messages that are transmitted. The two 
nodes see each other as symmetric neighbors but routes are never added to 
the routing table. 

According to the RFC, this configuration (i.e., neighbor nodes with no 
MPRs and no TC messages being sent; HELLOs only) should result in each 
node having a route to the other. Indeed, this worked in 0.4.10 version of 
olsrd.

Does anyone know of a bug or issue in version 0.5.4 that would cause this 
behaviour?

Thanks in advance,
Patricia Deutsch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090209/91e200c3/attachment.html>

From (spam-protected)  Mon Feb  9 20:53:11 2009
From: (spam-protected) (ZioPRoTo (Saverio Proto))
Date: Mon, 9 Feb 2009 20:53:11 +0100
Subject: [Olsr-users] OLSR and IPv4-IPv6 dual stack
Message-ID: <a5e23ab90902091153y7f6eb8cfn5b78052c2831791b@mail.gmail.com>

Hello,

As far as I know if I want to run OLSR on both IPv4 and IPv6 I have to
run two separate instances, one configured for IPv4 and one configured
for IPv6.

I know this works because I tried it last August.

Is this the right way to configure OLSR if I want my nodes to run both
IPv4 and IPv6 ??

Thank you :)

Saverio Proto



From (spam-protected)  Mon Feb  9 21:07:07 2009
From: (spam-protected) (Henning Rogge)
Date: Mon, 9 Feb 2009 21:07:07 +0100
Subject: [Olsr-users] OLSR and IPv4-IPv6 dual stack
In-Reply-To: <a5e23ab90902091153y7f6eb8cfn5b78052c2831791b@mail.gmail.com>
References: <a5e23ab90902091153y7f6eb8cfn5b78052c2831791b@mail.gmail.com>
Message-ID: <200902092107.12140.hrogge@googlemail.com>

On Montag 09 Februar 2009 20:53:11 ZioPRoTo (Saverio Proto) wrote:
> Hello,
>
> As far as I know if I want to run OLSR on both IPv4 and IPv6 I have to
> run two separate instances, one configured for IPv4 and one configured
> for IPv6.
>
> I know this works because I tried it last August.
>
> Is this the right way to configure OLSR if I want my nodes to run both
> IPv4 and IPv6 ??
The problem is that OLSRv1 has no way to determine the length of the address 
fields in the OLSR messages except by looking up an external value. 
Theoretically it should be possible to run OLSR in pure IPv6 mode and use the 
IPv4 legacy addresses in IPv6.

OLSRv2 (the packetbb packet format) can do it, because the address length is 
encoded in the header of each message.

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090209/790f4ccb/attachment.sig>

From (spam-protected)  Fri Feb 13 05:55:32 2009
From: (spam-protected) (Bhat, Ishwara)
Date: Fri, 13 Feb 2009 10:25:32 +0530
Subject: [Olsr-users] Suggested OLSR Timer Values
Message-ID: <1106299A6DFA0E4D8E13CFD83A7611F001CACA5D@IE10EV813.global.ds.honeywell.com>

Hi,

 

I have a question about OLSR timers. My usage mode is such that 

 

1.	All newly joined nodes shall be known within 1 second. 
2.	Any node dropped out of network shall be known in 1 second.
(Mandatory for 1-hop links. Other mesh nodes- 1 sec desired; But can be
delayed).
3.	I have only 4 nodes in this mode, mostly in linear topology.

 

What is the suggested timer values? 

 

HelloInterval 0.5 

HelloValidity 0.5

TC Interval  0.5

TCValidity Interval   0.5

 

 

When I tested in a 2 node system,

1.	The hellos seem to work well in recognizing the new nodes. 
2.	But for loss of any existing node, it appears to take about 5
seconds. 

 

I was hoping that since upon TCValidity expiry, mesh would expect fresh
topology info and would invalidate existing information. 

 

I observed that irrespective of timers the 1-hop links are retained till
ETX is 3. (Just that with shorter timers, the value is calculated more
frequently and this has some effect on the link loss declaration. But
still could not detect link loss in a second).

 

Please tell me what values would achieve the link loss detection of 1 or
2 seconds.

 

Also with short TC timers won't the control traffic choke the network ?
While using OLSR should I resist any specification of the order of 1
second ?

 

 

Thanks,

Ishwar

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090213/792ac83a/attachment.html>

From (spam-protected)  Fri Feb 13 08:14:48 2009
From: (spam-protected) (Henning Rogge)
Date: Fri, 13 Feb 2009 08:14:48 +0100
Subject: [Olsr-users] Suggested OLSR Timer Values
In-Reply-To: <1106299A6DFA0E4D8E13CFD83A7611F001CACA5D@IE10EV813.global.ds.honeywell.com>
References: <1106299A6DFA0E4D8E13CFD83A7611F001CACA5D@IE10EV813.global.ds.honeywell.com>
Message-ID: <200902130814.53680.rogge@fgan.de>

Am Friday 13 February 2009 05:55:32 schrieb Bhat, Ishwara:
> Hi,
>
> I have a question about OLSR timers. My usage mode is such that
>
> 1.	All newly joined nodes shall be known within 1 second.
> 2.	Any node dropped out of network shall be known in 1 second.
> (Mandatory for 1-hop links. Other mesh nodes- 1 sec desired; But can be
> delayed).
> 3.	I have only 4 nodes in this mode, mostly in linear topology.
>
> What is the suggested timer values?
>
> HelloInterval 0.5
> HelloValidity 0.5
> TC Interval  0.5
> TCValidity Interval   0.5
It cannot work this way... set the validity time AT LEAST to 5 times the 
corresponding interval.

Try something like this:

HelloInterval 0.2
HelloValidity 2.0
TCInterval 0.5
TCValidity 3

This values will only work for small networks, but they should increase the 
speed of node detection and deletion.
Do NOT use etx_ff (it only creates ONE LQ value each second), use etx_fpm as 
your lq algorithm.

> When I tested in a 2 node system,
>
> 1.	The hellos seem to work well in recognizing the new nodes.
> 2.	But for loss of any existing node, it appears to take about 5
> seconds.
>
> I was hoping that since upon TCValidity expiry, mesh would expect fresh
> topology info and would invalidate existing information.

> I observed that irrespective of timers the 1-hop links are retained till
> ETX is 3. (Just that with shorter timers, the value is calculated more
> frequently and this has some effect on the link loss declaration. But
> still could not detect link loss in a second).
With validity = interval you sometimes loose a hello link just because you 
missed a single hello !

> Please tell me what values would achieve the link loss detection of 1 or
> 2 seconds.
>
> Also with short TC timers won't the control traffic choke the network ?
> While using OLSR should I resist any specification of the order of 1
> second ?
Of course it will. That's the tradeof.

No, OLSR will work fine with highspeed settings, but you should keep your 
network small.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090213/079a454f/attachment.sig>

From (spam-protected)  Wed Feb 18 21:05:22 2009
From: (spam-protected) (Derek C)
Date: Wed, 18 Feb 2009 20:05:22 -0000 (UTC)
Subject: [Olsr-users] OLSRd - can't understand routing
Message-ID: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>

Hi all,

Me again.  I'm still testing a smallish network (around 10 nodes but
spread over a couple of KM).

What I've done is put up three nodes with Internet access - the Internet
access is via 5.8Ghz point-to-point links and I've linked eth0 of my OLSRd
(PC engines WRAP boards) to via transparent [tunnel] bridges back to a NIC
on a DELL server running Ubuntu with OLSRd too.

This means that the three nodes all have a single hop to their gateway and
only one gateway - I thought this was a good idea to have no
connection/NAT problems associated with multiple gateways.

Currently all remote nodes are one-hop to an Internet connected node (i.e.
two logical/OLSRd hops to the DELL server in the datacentre).

What I don't understand is this:

If I go into a remote node and do a "netstat -rn" I can see that it has a
default route via a nearby Internet connected node - good stuff - and the
node has Internet access too - perfect!.

BUT If I ssh into the DELL server (the only gateway HNA node) I sometimes
DONT see the remote node's IP in a "netstat -rn" and I cannot ping it
either.

I don't understand how that remote node is actually working and getting
traffic back & forth if the routing is not propagating across the OLSRd
routed network.

I'm not doing any funny stuff with NAT on the remote nodes (other than
NATTing 192.168.0.0/16 so that people get Internet access of a public AP
in the nodes - my OLSRd network is 5.0.0.0/8.

Does the above make any sense to anyone?

thanks v much!


Derek

P.S.
One of my typical remote OLSRd nodes:

UseHysteresis        no
TcRedundancy         2
MprCoverage          1
LinkQualityLevel     2
LinkQualityWinSize   10

DebugLevel	     0

#Hna4 {
#     0.0.0.0 0.0.0.0
#     }

#LoadPlugin "olsrd_dyn_gw.so.0.4"
#{
#    PlParam "Interval" "60"
#    PlParam "Ping" "151.1.1.1"
#    PlParam "Ping" "194.25.2.129"
#    }

LoadPlugin "olsrd_httpinfo.so.0.1"
{
    PlParam "Net" "5.0.0.0 255.0.0.0"
    PlParam "port" "8080"
    }

LoadPlugin "olsrd_txtinfo.so.0.1"
{
    PlParam "port" "8081"
    PlParam "Host" "127.0.0.1"
    }

Interface "ath0"
{
    Ip4Broadcast 255.255.255.255
    HelloInterval         2.0
    HelloValidityTime     20.0
    }






-- 
--
Derek C
In Ireland





From (spam-protected)  Wed Feb 18 21:09:01 2009
From: (spam-protected) (Derek C)
Date: Wed, 18 Feb 2009 20:09:01 -0000 (UTC)
Subject: [Olsr-users] Compatible network adapters for ad hoc networking
In-Reply-To: <2ced936d0902041008yf3aba9fn3fc77acfb6e54aeb@mail.gmail.com>
References: <2ced936d0902041008yf3aba9fn3fc77acfb6e54aeb@mail.gmail.com>
Message-ID: <35223.149.5.32.216.1234987741.squirrel@www.rivertowermail.com>

Hi Breno,

I had a *lot* of trouble with atheros/madwifi in adhoc mode.  When I
switched to the madwifi ahdemo mode things improved a great deal.  With
ahdemo mode there is SSID - only the fixed frequency selection.  This
didn't bother me.

I think adhoc modes cause problems when signal becomes poor (even for
short periods like dropping nodes?) and then the network breaks into two
(the different BSSIDs you saw I think).

Derek

On Wed, February 4, 2009 6:08 pm, Breno Jacinto wrote:
> Hello everyone,
>
>
> I`m running several experiments involving ad hoc networks. I`ve
> selected some well known-to-be-compatible adapters, such as Edimax (Ralink
> shipset), Alfa networks (Realtek) and Atheros (madwifi). Atheros is
> available only as built-in adapter on the equipement or as a  PCI board.
>
> So, I'm experiencing some instability regarding the selection of
> the BSSID used by all the nodes. I start the network with a single node,
> then another, then another. Now, for a couple of minutes it works, bu then
> some nodes start losing sight of each and changing their BSSIDs to a
> different value (when they should be in sync). I'm really running out of
> explanations of why this is happening, because these nodes are all
> in-range of each other, and should be "pingable" directly. My main suspect
> is the driver instability, but then I dont know of any other better
> alternatives. I've tested the following USB adapters:
>
> - Edimax EW-7318USg (rt73 drivers)
> - Alfa AWUS036H-11g
>
>
> And the builtin adapters:
>
>
> - Atheros chipset AR5007EG
>
>
>
> best regards,
>
> --
> --
> :: Breno Jacinto ::
> :: breno - at - gprt.ufpe.br ::
> :: FingerPrint ::
> 2F15 8A61 F566 E442 8581
> E3C0 EFF4 E202 74B7 7484
> :: Persistir no difícil é a única maneira de torná-lo fácil algum dia.  ::
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
>


-- 
--
Derek C
In Ireland





From (spam-protected)  Wed Feb 18 23:03:05 2009
From: (spam-protected) (Derek C)
Date: Wed, 18 Feb 2009 22:03:05 -0000 (UTC)
Subject: [Olsr-users] OLSRd - can't understand routing
In-Reply-To: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
Message-ID: <56082.149.5.32.216.1234994585.squirrel@www.rivertowermail.com>

Hi all again,

I've been investigating further and I see some weird routing stuff.

My setup is like this: -

    |
  INTERNET
    |
   NIC1 (Internet connection with NAT)
 UBUNTU SERVER
   NIC2 (5.0.0.1 with OLSRd)
    |
 5GHZ-RADIO--------
  |     |         | (Transparent bridges - radio links - 1KM)
  |     |         |
  |     |         |
 ETH0  ETH0      ETH0
OLSRD1   OLSRD2   OLSRD3
 2.4GHZ   2.4GHZ   2.4GHZ
5.1.0.1  5.1.0.2   5.1.0.3

And those antennas pick up about 10 remote nodes (5.10.0.1 - 5.10.0.10)

The weird thing is this:

I have a remote node that is showing up in the main server as being
available at 5.1.0.1.  So I ssh in there and find that it thinks that node
is available via 5.1.0.3 (which it really is as that's where it is
geographically located).

I wonder why OLSRd, in the main Ubuntu server, thinks the remote node is
available via the wrong node?

It could be my transparent bridging but I wouldn't have thought so?

thanks for any advice!

Derek
On Wed, February 18, 2009 8:05 pm, Derek C wrote:
> Hi all,
>
>
> Me again.  I'm still testing a smallish network (around 10 nodes but
> spread over a couple of KM).
>
> What I've done is put up three nodes with Internet access - the Internet
> access is via 5.8Ghz point-to-point links and I've linked eth0 of my OLSRd
>  (PC engines WRAP boards) to via transparent [tunnel] bridges back to a
> NIC
> on a DELL server running Ubuntu with OLSRd too.
>
> This means that the three nodes all have a single hop to their gateway
> and only one gateway - I thought this was a good idea to have no
> connection/NAT problems associated with multiple gateways.
>
> Currently all remote nodes are one-hop to an Internet connected node
> (i.e.
> two logical/OLSRd hops to the DELL server in the datacentre).
>
> What I don't understand is this:
>
>
> If I go into a remote node and do a "netstat -rn" I can see that it has a
>  default route via a nearby Internet connected node - good stuff - and
> the node has Internet access too - perfect!.
>
> BUT If I ssh into the DELL server (the only gateway HNA node) I sometimes
>  DONT see the remote node's IP in a "netstat -rn" and I cannot ping it
> either.
>
> I don't understand how that remote node is actually working and getting
> traffic back & forth if the routing is not propagating across the OLSRd
> routed network.
>
> I'm not doing any funny stuff with NAT on the remote nodes (other than
> NATTing 192.168.0.0/16 so that people get Internet access of a public AP
> in the nodes - my OLSRd network is 5.0.0.0/8.
>
> Does the above make any sense to anyone?
>
>
> thanks v much!
>
>
> Derek
>
>
> P.S.
> One of my typical remote OLSRd nodes:
>
>
> UseHysteresis        no
> TcRedundancy         2
> MprCoverage          1
> LinkQualityLevel     2
> LinkQualityWinSize   10
>
>
> DebugLevel	     0
>
>
> #Hna4 {
> #     0.0.0.0 0.0.0.0
> #     }
>
>
> #LoadPlugin "olsrd_dyn_gw.so.0.4"
> #{
> #    PlParam "Interval" "60"
> #    PlParam "Ping" "151.1.1.1"
> #    PlParam "Ping" "194.25.2.129"
> #    }
>
>
> LoadPlugin "olsrd_httpinfo.so.0.1"
> {
> PlParam "Net" "5.0.0.0 255.0.0.0"
> PlParam "port" "8080"
> }
>
>
> LoadPlugin "olsrd_txtinfo.so.0.1"
> {
> PlParam "port" "8081"
> PlParam "Host" "127.0.0.1"
> }
>
>
> Interface "ath0"
> {
> Ip4Broadcast 255.255.255.255
> HelloInterval         2.0
> HelloValidityTime     20.0
> }
>
>
>
>
>
>
>
> --
> --
> Derek C
> In Ireland
>
>
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
>


-- 
--
Derek C
In Ireland





From (spam-protected)  Thu Feb 19 00:47:22 2009
From: (spam-protected) (Derek C)
Date: Wed, 18 Feb 2009 23:47:22 -0000 (UTC)
Subject: [Olsr-users] UPDATE: OLSRd - can't understand routing
In-Reply-To: <56082.149.5.32.216.1234994585.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
	<56082.149.5.32.216.1234994585.squirrel@www.rivertowermail.com>
Message-ID: <52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>

Hi [yet] again.

I told a lie.. On more checking I see what's up - still weird...

I have three main OLSRd antennas all connected back to one main OLSRd
Internet gateway.  I use bridges to link them to the gateway server but
that shouldn't matter I guess.  Like this; -

GATEWAY OLSRd SERVER - 5.0.0.1
    |          |            |
    |          |            |
   ETH0       ETH0         ETH0
  5.1.0.1   5.1.0.2      5.1.0.3
  OLSRd1    OLSRd2       OLSRd3
  5.2.0.1   5.2.0.2      5.2.0.3
   ANT        ANT          ANT


Now - what's happening is that I have a remote OLSRd node out there - It's
nearest neighbor is 5.2.0.3.  You'd expect the gateway server to see if
via 5.1.0.3 *but* what's happening is that the route is: -

 5.0.0.1 --> 5.1.0.1/5.2.0.1 --> 5.2.0.3

this is because it turns out that the antenna on OLSRd1 (5.2.0.1) is also
able to talk to OLSRd3 (5.2.0.3) even though the [better faster] backhaul
(via ETH ports) is availabe.

I have "Weight 0" in the eth0 section of the oslrd.conf for the three
units so I though that that would do the job but apparently not.

Do you know how to stop this situation?

thanks,

Derek




On Wed, February 18, 2009 10:03 pm, Derek C wrote:
> Hi all again,
>
>
> I've been investigating further and I see some weird routing stuff.
>
>
> My setup is like this: -
>
>
> |
> INTERNET
> |
> NIC1 (Internet connection with NAT)
> UBUNTU SERVER
> NIC2 (5.0.0.1 with OLSRd)
> |
> 5GHZ-RADIO--------
> |     |         | (Transparent bridges - radio links - 1KM)
> |     |         |
> |     |         |
> ETH0  ETH0      ETH0
> OLSRD1   OLSRD2   OLSRD3
> 2.4GHZ   2.4GHZ   2.4GHZ
> 5.1.0.1  5.1.0.2   5.1.0.3
>
>
> And those antennas pick up about 10 remote nodes (5.10.0.1 - 5.10.0.10)
>
>
> The weird thing is this:
>
>
> I have a remote node that is showing up in the main server as being
> available at 5.1.0.1.  So I ssh in there and find that it thinks that node
>  is available via 5.1.0.3 (which it really is as that's where it is
> geographically located).
>
> I wonder why OLSRd, in the main Ubuntu server, thinks the remote node is
> available via the wrong node?
>
> It could be my transparent bridging but I wouldn't have thought so?
>
>
> thanks for any advice!
>
> Derek
> On Wed, February 18, 2009 8:05 pm, Derek C wrote:
>
>> Hi all,
>>
>>
>>
>> Me again.  I'm still testing a smallish network (around 10 nodes but
>> spread over a couple of KM).
>>
>> What I've done is put up three nodes with Internet access - the
>> Internet
>> access is via 5.8Ghz point-to-point links and I've linked eth0 of my
>> OLSRd
>> (PC engines WRAP boards) to via transparent [tunnel] bridges back to a
>> NIC
>> on a DELL server running Ubuntu with OLSRd too.
>>
>> This means that the three nodes all have a single hop to their gateway
>> and only one gateway - I thought this was a good idea to have no
>> connection/NAT problems associated with multiple gateways.
>>
>> Currently all remote nodes are one-hop to an Internet connected node
>> (i.e.
>> two logical/OLSRd hops to the DELL server in the datacentre).
>>
>> What I don't understand is this:
>>
>>
>>
>> If I go into a remote node and do a "netstat -rn" I can see that it has
>> a default route via a nearby Internet connected node - good stuff - and
>> the node has Internet access too - perfect!.
>>
>> BUT If I ssh into the DELL server (the only gateway HNA node) I
>> sometimes DONT see the remote node's IP in a "netstat -rn" and I cannot
>> ping it either.
>>
>> I don't understand how that remote node is actually working and getting
>>  traffic back & forth if the routing is not propagating across the
>> OLSRd
>> routed network.
>>
>> I'm not doing any funny stuff with NAT on the remote nodes (other than
>> NATTing 192.168.0.0/16 so that people get Internet access of a public AP
>>  in the nodes - my OLSRd network is 5.0.0.0/8.
>>
>> Does the above make any sense to anyone?
>>
>>
>>
>> thanks v much!
>>
>>
>> Derek
>>
>>
>>
>> P.S.
>> One of my typical remote OLSRd nodes:
>>
>>
>>
>> UseHysteresis        no
>> TcRedundancy         2
>> MprCoverage          1
>> LinkQualityLevel     2
>> LinkQualityWinSize   10
>>
>>
>>
>> DebugLevel	     0
>>
>>
>>
>> #Hna4 {
>> #     0.0.0.0 0.0.0.0
>> #     }
>>
>>
>>
>> #LoadPlugin "olsrd_dyn_gw.so.0.4"
>> #{
>> #    PlParam "Interval" "60"
>> #    PlParam "Ping" "151.1.1.1"
>> #    PlParam "Ping" "194.25.2.129"
>> #    }
>>
>>
>>
>> LoadPlugin "olsrd_httpinfo.so.0.1"
>> {
>> PlParam "Net" "5.0.0.0 255.0.0.0"
>> PlParam "port" "8080"
>> }
>>
>>
>>
>> LoadPlugin "olsrd_txtinfo.so.0.1"
>> {
>> PlParam "port" "8081"
>> PlParam "Host" "127.0.0.1"
>> }
>>
>>
>>
>> Interface "ath0"
>> {
>> Ip4Broadcast 255.255.255.255
>> HelloInterval         2.0
>> HelloValidityTime     20.0
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> --
>> Derek C
>> In Ireland
>>
>>
>>
>>
>>
>> --
>> Olsr-users mailing list
>> Olsr-users at lists.olsr.org
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>>
>>
>
>
> --
> --
> Derek C
> In Ireland
>
>
>
>


-- 
--
Derek C
In Ireland





From (spam-protected)  Thu Feb 19 01:03:09 2009
From: (spam-protected) (Derek C)
Date: Thu, 19 Feb 2009 00:03:09 -0000 (UTC)
Subject: [Olsr-users] multiple default routes showing?
Message-ID: <43229.149.5.32.216.1235001789.squirrel@www.rivertowermail.com>

Hi again,

I notice that an OLSRd node appears to have two available routes
(multi-homed - in my case its the better eth0 link over the ath0 link)

netstat -rn shows: -

0.0.0.0         5.0.0.1         0.0.0.0         UG        0 0          0 eth1
0.0.0.0         5.2.0.1         0.0.0.0         UG        0 0          0 ath0

traceroute does show that the 1st route above (the better eth0 link) is
being used - good news.

But is it normal to see two default routes like this?  It seems a bit
strange to me

thanks,

Derek


-- 
--
Derek C
In Ireland





From (spam-protected)  Thu Feb 19 01:31:07 2009
From: (spam-protected) (Derek C)
Date: Thu, 19 Feb 2009 00:31:07 -0000 (UTC)
Subject: [Olsr-users] NOW SIMPLEST EXAMPLE: OLSRd - can't understand routing
In-Reply-To: <52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com> 
	<56082.149.5.32.216.1234994585.squirrel@www.rivertowermail.com>
	<52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>
Message-ID: <41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com>

Hi again,

Ok - I'm still at this and here is the simplest example of all - it
happens when two multi-homed OLSRd nodes are close enough together for
their customer antennas to chat together and it is taking preference over
the backhaul route: -


GATEWAY OLSRd SERVER - 5.0.0.1
 |          |            |
 |          |            |
 ETH0       ETH0         ETH0
 5.1.0.1   5.1.0.2      5.1.0.3
 OLSRd1    OLSRd2       OLSRd3
 5.2.0.1   5.2.0.2 ---- 5.2.0.3
 ATH0        ATH0          ATH0

This is what is happening to me:  Above you can see that the 2.4Ghz
customer omnis on ATH0 interfaces can chat to each over (5.2.0.2 and
5.2.0.3) due to being around 800 Mtrs from each other

As a result a "traceroute -n 5.2.0.3" from the gateway OLSRd server
(5.0.0.1) gives the following: -

 1  5.1.0.1  2.466 ms  3.047 ms  3.039 ms
 2  5.2.0.3  8.326 ms  8.993 ms  9.000 ms

I want the routing to go via the eth0 interfaces as its the better faster
backhaul (5.8Ghz point-to-point) route.

Is there a way do correct this?

thanks very much,

Derek








-- 
--
Derek C
In Ireland





From (spam-protected)  Mon Feb 23 14:49:27 2009
From: (spam-protected) (Henning Rogge)
Date: Mon, 23 Feb 2009 14:49:27 +0100
Subject: [Olsr-users] NOW SIMPLEST EXAMPLE: OLSRd - can't understand
	routing
In-Reply-To: <41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
	<52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>
	<41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com>
Message-ID: <200902231449.33178.hrogge@googlemail.com>

On Donnerstag 19 Februar 2009 01:31:07 Derek C wrote:
> Hi again,
>
> Ok - I'm still at this and here is the simplest example of all - it
> happens when two multi-homed OLSRd nodes are close enough together for
> their customer antennas to chat together and it is taking preference over
> the backhaul route: -
Sorry that noone replied do your mail earlier, but let's see what we have got 
here...

> GATEWAY OLSRd SERVER - 5.0.0.1
>
>
>  ETH0       ETH0         ETH0
>  5.1.0.1   5.1.0.2      5.1.0.3
>  OLSRd1    OLSRd2       OLSRd3
>  5.2.0.1   5.2.0.2 ---- 5.2.0.3
>  ATH0        ATH0          ATH0
>
> This is what is happening to me:  Above you can see that the 2.4Ghz
> customer omnis on ATH0 interfaces can chat to each over (5.2.0.2 and
> 5.2.0.3) due to being around 800 Mtrs from each other
How do you use the eth0 interface ? Is it an additional OLSR interface or do 
you just define a HNA domain ?

If it's an HNA it might explain your problem, because OLSR is not designed to 
use HNA as shortcut to other parts of the OLSR mesh. You have to use it as 
mesh interface too or build up a VPN tunnel through the backbone between the 
OLSR instances (which will then be used as an additional OLSR interface).

> As a result a "traceroute -n 5.2.0.3" from the gateway OLSRd server
> (5.0.0.1) gives the following: -
>
>  1  5.1.0.1  2.466 ms  3.047 ms  3.039 ms
>  2  5.2.0.3  8.326 ms  8.993 ms  9.000 ms
>
> I want the routing to go via the eth0 interfaces as its the better faster
> backhaul (5.8Ghz point-to-point) route.

What happens if you just use the backbone links as  additional OLSR interface 
(which will have a nearly perfect ETX value I think) ?

> Is there a way do correct this?
>
> thanks very much,
Could you maybe post your olsrd.conf and the version of your olsrd routing 
daemon ? This might help...

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090223/e587562a/attachment.sig>

From (spam-protected)  Mon Feb 23 23:12:09 2009
From: (spam-protected) (Derek C)
Date: Mon, 23 Feb 2009 22:12:09 -0000 (UTC)
Subject: [Olsr-users] NOW SIMPLEST EXAMPLE: OLSRd - can't understand
 routing
In-Reply-To: <200902231449.33178.hrogge@googlemail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
	<52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>
	<41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com>
	<200902231449.33178.hrogge@googlemail.com>
Message-ID: <57059.149.5.32.216.1235427129.squirrel@www.rivertowermail.com>

Hi Henning,

> Sorry that noone replied do your mail earlier, but let's see what we have
> got here...

No problem - its great to be able to get help!

>> ETH0       ETH0         ETH0
>> 5.1.0.1   5.1.0.2      5.1.0.3
>> OLSRd1    OLSRd2       OLSRd3
>> 5.2.0.1   5.2.0.2 ---- 5.2.0.3
>> ATH0        ATH0          ATH0

> How do you use the eth0 interface ? Is it an additional OLSR interface or
> do you just define a HNA domain ?

It's just setup as an additional OLSRd interface.

Actually I did try setting a HNA 0.0.0.0 route to see what would happen -
it was interesting:  Normally (with the ath0 and eth0 OLSRd interfaces) I
have two default routes showing but with the HNA settings in there (with
NO other changes to the ath0 or eth0 settings) I only got one [better
looking] default route.  Still.. I didn't leave it this way because it
just seemed wrong.

> If it's an HNA it might explain your problem, because OLSR is not
> designed to use HNA as shortcut to other parts of the OLSR mesh. You have
> to use it as mesh interface too or build up a VPN tunnel through the
> backbone between the OLSR instances (which will then be used as an
> additional OLSR interface).

My "backhaul" is Mikrotik routerboards with XR5 cards and they are
transparently bridging their ethernet ports to the datacentre end so the
x86 boards running openwrt & OLSRd "see" their ethX port as being
connected directly to a server running OLSRd itself (where it is the only
device with a HNA 0.0.0.0/0 entry).

> What happens if you just use the backbone links as  additional OLSR
> interface (which will have a nearly perfect ETX value I think) ?

Yes - this is what I'm doing.  Initially I had no difference in settings
for ath0 and eth0.  More recently I tried putting in "LinkQualityMult"
entries but it doesn't seem to have any affect.

> Could you maybe post your olsrd.conf and the version of your olsrd
> routing daemon ? This might help...


This is the details of the 5.1.0.3/5.2.0.3 board (as per my diagram): -

Note:  All IPs beginning with 5.10 are OLSRd boxes (single radio card test
client units).  All IPs beginning with 5.1 are the ethX ports of my x86
gateway boards and all IPs beginning with 5.2 are the athX ports of the
same gateway boards.

netstat -rn: -

Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
5.10.0.6        0.0.0.0         255.255.255.255 UH        0 0          0 ath0
5.10.0.7        0.0.0.0         255.255.255.255 UH        0 0          0 ath0
5.10.0.4        5.2.0.1         255.255.255.255 UGH       0 0          0 ath0
5.0.0.1         5.2.0.1         255.255.255.255 UGH       0 0          0 ath0
5.10.0.2        5.2.0.1         255.255.255.255 UGH       0 0          0 ath0
5.2.0.2         5.2.0.1         255.255.255.255 UGH       0 0          0 ath0
5.10.0.3        0.0.0.0         255.255.255.255 UH        0 0          0 ath0
5.10.0.1        5.2.0.1         255.255.255.255 UGH       0 0          0 ath0
5.2.0.1         0.0.0.0         255.255.255.255 UH        0 0          0 ath0
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 ath1
192.168.182.0   0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
5.0.0.0         0.0.0.0         255.0.0.0       U         0 0          0 eth1
5.0.0.0         0.0.0.0         255.0.0.0       U         0 0          0 ath0
0.0.0.0         5.0.0.1         0.0.0.0         UG        0 0          0 eth1
0.0.0.0         5.2.0.1         0.0.0.0         UG        0 0          0 ath0

olsrd.conf:

root at OpenWrt:~# cat /etc/olsrd.conf
UseHysteresis        no
TcRedundancy         2
MprCoverage          1
LinkQualityLevel     2
LinkQualityWinSize   10

DebugLevel	     0

#Hna4 {
#     0.0.0.0 0.0.0.0
#     }

#LoadPlugin "olsrd_dyn_gw.so.0.4"
#{
#    PlParam "Interval" "60"
#    PlParam "Ping" "151.1.1.1"
#    PlParam "Ping" "194.25.2.129"
#    }

LoadPlugin "olsrd_httpinfo.so.0.1"
{
    PlParam "Net" "5.0.0.0 255.0.0.0"
    PlParam "port" "8080"
    }

#LoadPlugin "olsrd_txtinfo.so.0.1"
#{
#    PlParam "port" "8081"
#    PlParam "Host" "127.0.0.1"
#    }

Interface "ath0"
{
    Ip4Broadcast 255.255.255.255
    HelloValidityTime     20.0
    HelloInterval         2.0
    #LinkQualityMult default 0.1
    }

Interface "eth0"
{
    Ip4Broadcast 255.255.255.255
    HelloValidityTime     20.0
    HelloInterval         2.0
    #Weight 0
    LinkQualityMult 0.0.0.0 2.00
    }





>


> Henning
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users


-- 
--
Derek C
In Ireland





From (spam-protected)  Mon Feb 23 23:22:48 2009
From: (spam-protected) (Derek C)
Date: Mon, 23 Feb 2009 22:22:48 -0000 (UTC)
Subject: [Olsr-users] OOPS!!!!!!!!!!!!!!!!!!! Re: NOW SIMPLEST EXAMPLE:
 OLSRd - can't understand routing
In-Reply-To: <57059.149.5.32.216.1235427129.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com>
	<52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com>
	<41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com>
	<200902231449.33178.hrogge@googlemail.com>
	<57059.149.5.32.216.1235427129.squirrel@www.rivertowermail.com>
Message-ID: <41747.149.5.32.216.1235427768.squirrel@www.rivertowermail.com>

Oops,

Hold on.... I just see how that I'm specifying "eth0" as my OLSRd NIC
whereas it actually should be eth1 (error in my olsrd.conf).

I'm fixing this now....

So stupid I know....

Derek






On Mon, February 23, 2009 10:12 pm, Derek C wrote:
> Hi Henning,
>
>
>> Sorry that noone replied do your mail earlier, but let's see what we
>> have got here...
>
> No problem - its great to be able to get help!
>
>
>>> ETH0       ETH0         ETH0
>>> 5.1.0.1   5.1.0.2      5.1.0.3
>>> OLSRd1    OLSRd2       OLSRd3
>>> 5.2.0.1   5.2.0.2 ---- 5.2.0.3
>>> ATH0        ATH0          ATH0
>>>
>
>> How do you use the eth0 interface ? Is it an additional OLSR interface
>> or do you just define a HNA domain ?
>
> It's just setup as an additional OLSRd interface.
>
>
> Actually I did try setting a HNA 0.0.0.0 route to see what would happen -
>  it was interesting:  Normally (with the ath0 and eth0 OLSRd interfaces)
> I
> have two default routes showing but with the HNA settings in there (with NO
> other changes to the ath0 or eth0 settings) I only got one [better
> looking] default route.  Still.. I didn't leave it this way because it
> just seemed wrong.
>
>> If it's an HNA it might explain your problem, because OLSR is not
>> designed to use HNA as shortcut to other parts of the OLSR mesh. You
>> have to use it as mesh interface too or build up a VPN tunnel through
>> the backbone between the OLSR instances (which will then be used as an
>> additional OLSR interface).
>
> My "backhaul" is Mikrotik routerboards with XR5 cards and they are
> transparently bridging their ethernet ports to the datacentre end so the
> x86 boards running openwrt & OLSRd "see" their ethX port as being
> connected directly to a server running OLSRd itself (where it is the only
>  device with a HNA 0.0.0.0/0 entry).
>
>> What happens if you just use the backbone links as  additional OLSR
>> interface (which will have a nearly perfect ETX value I think) ?
>
> Yes - this is what I'm doing.  Initially I had no difference in settings
> for ath0 and eth0.  More recently I tried putting in "LinkQualityMult"
> entries but it doesn't seem to have any affect.
>
>> Could you maybe post your olsrd.conf and the version of your olsrd
>> routing daemon ? This might help...
>
>
> This is the details of the 5.1.0.3/5.2.0.3 board (as per my diagram): -
>
>
> Note:  All IPs beginning with 5.10 are OLSRd boxes (single radio card
> test client units).  All IPs beginning with 5.1 are the ethX ports of my
> x86 gateway boards and all IPs beginning with 5.2 are the athX ports of
> the same gateway boards.
>
> netstat -rn: -
>
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 5.10.0.6        0.0.0.0         255.255.255.255 UH        0 0          0
> ath0 5.10.0.7        0.0.0.0         255.255.255.255 UH        0 0
> 0 ath0 5.10.0.4        5.2.0.1         255.255.255.255 UGH       0 0
> 0 ath0 5.0.0.1         5.2.0.1         255.255.255.255 UGH       0 0
> 0 ath0 5.10.0.2        5.2.0.1         255.255.255.255 UGH       0 0
> 0 ath0 5.2.0.2         5.2.0.1         255.255.255.255 UGH       0 0
> 0 ath0 5.10.0.3        0.0.0.0         255.255.255.255 UH        0 0
> 0 ath0 5.10.0.1        5.2.0.1         255.255.255.255 UGH       0 0
> 0 ath0 5.2.0.1         0.0.0.0         255.255.255.255 UH        0 0
> 0 ath0 192.168.100.0   0.0.0.0         255.255.255.0   U         0 0
> 0 ath1 192.168.182.0   0.0.0.0         255.255.255.0   U         0 0
> 0 tun0 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0
> 0 eth0 5.0.0.0         0.0.0.0         255.0.0.0       U         0 0
> 0 eth1 5.0.0.0         0.0.0.0         255.0.0.0       U         0 0
> 0 ath0 0.0.0.0         5.0.0.1         0.0.0.0         UG        0 0
> 0 eth1 0.0.0.0         5.2.0.1         0.0.0.0         UG        0 0
> 0 ath0
>
> olsrd.conf:
>
>
> root at OpenWrt:~# cat /etc/olsrd.conf
> UseHysteresis        no
> TcRedundancy         2
> MprCoverage          1
> LinkQualityLevel     2
> LinkQualityWinSize   10
>
>
> DebugLevel	     0
>
>
> #Hna4 {
> #     0.0.0.0 0.0.0.0
> #     }
>
>
> #LoadPlugin "olsrd_dyn_gw.so.0.4"
> #{
> #    PlParam "Interval" "60"
> #    PlParam "Ping" "151.1.1.1"
> #    PlParam "Ping" "194.25.2.129"
> #    }
>
>
> LoadPlugin "olsrd_httpinfo.so.0.1"
> {
> PlParam "Net" "5.0.0.0 255.0.0.0"
> PlParam "port" "8080"
> }
>
>
> #LoadPlugin "olsrd_txtinfo.so.0.1"
> #{
> #    PlParam "port" "8081"
> #    PlParam "Host" "127.0.0.1"
> #    }
>
>
> Interface "ath0"
> {
> Ip4Broadcast 255.255.255.255
> HelloValidityTime     20.0
> HelloInterval         2.0
> #LinkQualityMult default 0.1
> }
>
>
> Interface "eth0"
> {
> Ip4Broadcast 255.255.255.255
> HelloValidityTime     20.0
> HelloInterval         2.0
> #Weight 0
> LinkQualityMult 0.0.0.0 2.00
> }
>
>
>
>
>
>
>>
>
>
>> Henning
>>
>>
>>
>> --
>> Olsr-users mailing list
>> Olsr-users at lists.olsr.org
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>
>
> --
> --
> Derek C
> In Ireland
>
>
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
>


-- 
--
Derek C
In Ireland





From (spam-protected)  Mon Feb 23 23:27:22 2009
From: (spam-protected) (Derek C)
Date: Mon, 23 Feb 2009 22:27:22 -0000 (UTC)
Subject: [Olsr-users] OOPS!!!!!!!!!!!!!!!!!!! Re: NOW SIMPLEST EXAMPLE:
 OLSRd - can't understand routing
In-Reply-To: <41747.149.5.32.216.1235427768.squirrel@www.rivertowermail.com>
References: <35814.149.5.32.216.1234987522.squirrel@www.rivertowermail.com> 
	<52990.149.5.32.216.1235000842.squirrel@www.rivertowermail.com> 
	<41696.149.5.32.216.1235003467.squirrel@www.rivertowermail.com> 
	<200902231449.33178.hrogge@googlemail.com>   
	<57059.149.5.32.216.1235427129.squirrel@www.rivertowermail.com>
	<41747.149.5.32.216.1235427768.squirrel@www.rivertowermail.com>
Message-ID: <35442.149.5.32.216.1235428042.squirrel@www.rivertowermail.com>

Instantly all looking better..

:-|  Sorry about that!

Derek

On Mon, February 23, 2009 10:22 pm, Derek C wrote:
> Oops,
>
>
> Hold on.... I just see how that I'm specifying "eth0" as my OLSRd NIC
> whereas it actually should be eth1 (error in my olsrd.conf).
>
> I'm fixing this now....
>
>
> So stupid I know....
>
>
> Derek
>
>
>
>
>
>
>
> On Mon, February 23, 2009 10:12 pm, Derek C wrote:
>
>> Hi Henning,
>>
>>
>>
>>> Sorry that noone replied do your mail earlier, but let's see what we
>>> have got here...
>>
>> No problem - its great to be able to get help!
>>
>>
>>
>>>> ETH0       ETH0         ETH0
>>>> 5.1.0.1   5.1.0.2      5.1.0.3
>>>> OLSRd1    OLSRd2       OLSRd3
>>>> 5.2.0.1   5.2.0.2 ---- 5.2.0.3
>>>> ATH0        ATH0          ATH0
>>>>
>>>>
>>
>>> How do you use the eth0 interface ? Is it an additional OLSR
>>> interface or do you just define a HNA domain ?
>>
>> It's just setup as an additional OLSRd interface.
>>
>>
>>
>> Actually I did try setting a HNA 0.0.0.0 route to see what would happen
>> -
>> it was interesting:  Normally (with the ath0 and eth0 OLSRd interfaces) I
>>  have two default routes showing but with the HNA settings in there
>> (with NO
>> other changes to the ath0 or eth0 settings) I only got one [better
>> looking] default route.  Still.. I didn't leave it this way because it
>> just seemed wrong.
>>
>>> If it's an HNA it might explain your problem, because OLSR is not
>>> designed to use HNA as shortcut to other parts of the OLSR mesh. You
>>> have to use it as mesh interface too or build up a VPN tunnel through
>>>  the backbone between the OLSR instances (which will then be used as
>>> an additional OLSR interface).
>>
>> My "backhaul" is Mikrotik routerboards with XR5 cards and they are
>> transparently bridging their ethernet ports to the datacentre end so the
>>  x86 boards running openwrt & OLSRd "see" their ethX port as being
>> connected directly to a server running OLSRd itself (where it is the
>> only device with a HNA 0.0.0.0/0 entry).
>>
>>> What happens if you just use the backbone links as  additional OLSR
>>> interface (which will have a nearly perfect ETX value I think) ?
>>
>> Yes - this is what I'm doing.  Initially I had no difference in
>> settings for ath0 and eth0.  More recently I tried putting in
>> "LinkQualityMult"
>> entries but it doesn't seem to have any affect.
>>
>>> Could you maybe post your olsrd.conf and the version of your olsrd
>>> routing daemon ? This might help...
>>
>>
>> This is the details of the 5.1.0.3/5.2.0.3 board (as per my diagram): -
>>
>>
>>
>> Note:  All IPs beginning with 5.10 are OLSRd boxes (single radio card
>> test client units).  All IPs beginning with 5.1 are the ethX ports of my
>>  x86 gateway boards and all IPs beginning with 5.2 are the athX ports
>> of the same gateway boards.
>>
>> netstat -rn: -
>>
>> Destination     Gateway         Genmask         Flags   MSS Window
>> irtt Iface
>> 5.10.0.6        0.0.0.0         255.255.255.255 UH        0 0          0
>>  ath0 5.10.0.7        0.0.0.0         255.255.255.255 UH        0 0 0
>> ath0 5.10.0.4        5.2.0.1         255.255.255.255 UGH       0 0 0
>> ath0 5.0.0.1         5.2.0.1         255.255.255.255 UGH       0 0 0
>> ath0 5.10.0.2        5.2.0.1         255.255.255.255 UGH       0 0 0
>> ath0 5.2.0.2         5.2.0.1         255.255.255.255 UGH       0 0 0
>> ath0 5.10.0.3        0.0.0.0         255.255.255.255 UH        0 0 0
>> ath0 5.10.0.1        5.2.0.1         255.255.255.255 UGH       0 0 0
>> ath0 5.2.0.1         0.0.0.0         255.255.255.255 UH        0 0 0
>> ath0 192.168.100.0   0.0.0.0         255.255.255.0   U         0 0 0
>> ath1 192.168.182.0   0.0.0.0         255.255.255.0   U         0 0 0
>> tun0 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0 0
>> eth0 5.0.0.0         0.0.0.0         255.0.0.0       U         0 0 0
>> eth1 5.0.0.0         0.0.0.0         255.0.0.0       U         0 0 0
>> ath0 0.0.0.0         5.0.0.1         0.0.0.0         UG        0 0 0
>> eth1 0.0.0.0         5.2.0.1         0.0.0.0         UG        0 0 0
>> ath0
>>
>> olsrd.conf:
>>
>>
>>
>> root at OpenWrt:~# cat /etc/olsrd.conf
>> UseHysteresis        no
>> TcRedundancy         2
>> MprCoverage          1
>> LinkQualityLevel     2
>> LinkQualityWinSize   10
>>
>>
>>
>> DebugLevel	     0
>>
>>
>>
>> #Hna4 {
>> #     0.0.0.0 0.0.0.0
>> #     }
>>
>>
>>
>> #LoadPlugin "olsrd_dyn_gw.so.0.4"
>> #{
>> #    PlParam "Interval" "60"
>> #    PlParam "Ping" "151.1.1.1"
>> #    PlParam "Ping" "194.25.2.129"
>> #    }
>>
>>
>>
>> LoadPlugin "olsrd_httpinfo.so.0.1"
>> {
>> PlParam "Net" "5.0.0.0 255.0.0.0"
>> PlParam "port" "8080"
>> }
>>
>>
>>
>> #LoadPlugin "olsrd_txtinfo.so.0.1"
>> #{
>> #    PlParam "port" "8081"
>> #    PlParam "Host" "127.0.0.1"
>> #    }
>>
>>
>>
>> Interface "ath0"
>> {
>> Ip4Broadcast 255.255.255.255
>> HelloValidityTime     20.0
>> HelloInterval         2.0
>> #LinkQualityMult default 0.1
>> }
>>
>>
>>
>> Interface "eth0"
>> {
>> Ip4Broadcast 255.255.255.255
>> HelloValidityTime     20.0
>> HelloInterval         2.0
>> #Weight 0
>> LinkQualityMult 0.0.0.0 2.00
>> }
>>
>>
>>
>>
>>
>>
>>
>>>
>>
>>
>>> Henning
>>>
>>>
>>>
>>>
>>> --
>>> Olsr-users mailing list
>>> Olsr-users at lists.olsr.org
>>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>>
>>>
>>
>>
>> --
>> --
>> Derek C
>> In Ireland
>>
>>
>>
>>
>>
>> --
>> Olsr-users mailing list
>> Olsr-users at lists.olsr.org
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>>
>>
>
>
> --
> --
> Derek C
> In Ireland
>
>
>
>


-- 
--
Derek C
In Ireland





From (spam-protected)  Tue Feb 24 10:07:51 2009
From: (spam-protected) (Bhat, Ishwara)
Date: Tue, 24 Feb 2009 14:37:51 +0530
Subject: [Olsr-users] BMF Plugin
In-Reply-To: <200901291521.57705.rogge@fgan.de>
References: <1106299A6DFA0E4D8E13CFD83A7611F001B7C3FC@IE10EV813.global.ds.honeywell.com><200901291423.44986.rogge@fgan.de><1106299A6DFA0E4D8E13CFD83A7611F001B7C666@IE10EV813.global.ds.honeywell.com>
	<200901291521.57705.rogge@fgan.de>
Message-ID: <1106299A6DFA0E4D8E13CFD83A7611F001D73998@IE10EV813.global.ds.honeywell.com>


Hi,

I am re-opening an old chain on broadcasts on OLSR mesh.

I tried bmf plugin and unfortunately I do not have good results yet.

Here is what I did:
Node-1: 10.1.18.180
Node-2: 10.1.18.185

Both have bmf plugins and am able to see bmf0-00 upon ifconfig. 

For ping 224.0.0.1, the tcpdump -I bmf0 on same node logs the ICMP requests going out.
But on the receiver tcpdump -I bmf0 I get nothing.

Also I had set DoLocalBoradcasts to yes. But when I pinged 10.1.18.255 with -b option, even in the sender's bmf0, I do not see anything.

Please tell what could be wrong.

Thanks,
Ishwar

-----Original Message-----
From: olsr-users-bounces at lists.olsr.org [mailto:olsr-users-bounces at lists.olsr.org] On Behalf Of Henning Rogge
Sent: Thursday, January 29, 2009 7:52 PM
To: Bhat, Ishwara
Cc: olsr-users at lists.olsr.org
Subject: Re: [Olsr-users] BMF Plugin

Am Thursday 29 January 2009 14:33:34 schrieb Bhat, Ishwara:
> Thanks.I will try tcpdump and check the behavior.
> However when I did ping to my broadcast address, is it not supposed to
> broadcast this ping ? Even for local broadcast ping it did not return
> anything.
Sending a ping through the BMF plugin is not the same as sending a broadcast 
ping. Look into the BMF sourcecode for more information.

If you see the ICMP-requests on the receiver side (coming out of the tap 
device the BMF creates there) everything is fine.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)




From (spam-protected)  Tue Feb 24 17:25:49 2009
From: (spam-protected) (Henning Rogge)
Date: Tue, 24 Feb 2009 17:25:49 +0100
Subject: [Olsr-users] BMF Plugin
In-Reply-To: <1106299A6DFA0E4D8E13CFD83A7611F001D73998@IE10EV813.global.ds.honeywell.com>
References: <1106299A6DFA0E4D8E13CFD83A7611F001B7C3FC@IE10EV813.global.ds.honeywell.com>
	<200901291521.57705.rogge@fgan.de>
	<1106299A6DFA0E4D8E13CFD83A7611F001D73998@IE10EV813.global.ds.honeywell.com>
Message-ID: <200902241725.53836.hrogge@googlemail.com>

On Dienstag 24 Februar 2009 10:07:51 Bhat, Ishwara wrote:
> Hi,
>
> I am re-opening an old chain on broadcasts on OLSR mesh.
>
> I tried bmf plugin and unfortunately I do not have good results yet.
>
> Here is what I did:
> Node-1: 10.1.18.180
> Node-2: 10.1.18.185
>
> Both have bmf plugins and am able to see bmf0-00 upon ifconfig.
>
> For ping 224.0.0.1, the tcpdump -I bmf0 on same node logs the ICMP requests
> going out. But on the receiver tcpdump -I bmf0 I get nothing.
>
> Also I had set DoLocalBoradcasts to yes. But when I pinged 10.1.18.255 with
> -b option, even in the sender's bmf0, I do not see anything.
The BMF plugin use a hop-by-hop UDP encapsulation on port 50698. Can you see 
any UDP packages on this port on the main OLSR interface (not on bmf0) ?

Henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090224/f662a68c/attachment.sig>

From (spam-protected)  Wed Feb 25 02:26:51 2009
From: (spam-protected) (Derek C)
Date: Wed, 25 Feb 2009 01:26:51 -0000 (UTC)
Subject: [Olsr-users] AHCP
In-Reply-To: <5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com> 
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com> 
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com> 
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
Message-ID: <35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>

Hi OD,

You mentioned, last month, that you are automatically configuring your
node's IP addresses based on the MAC address (I think that's what you
mean).

Would you be able to detail how you do it?  (is it a shell script that
does it?).

I'm interesting it doing this too if possible to save on having to
allocate IPs manually - I'm interested to know how you base the IPs on the
MAC and know that you won't ever have IP duplication.

thanks,

Derek

On Fri, January 23, 2009 2:40 pm, Outback Dingo wrote:
> basically a script that runs ipcalc and the mac address of the interface,
> to create address space
>
--
Derek C
In Ireland





From (spam-protected)  Wed Feb 25 02:40:29 2009
From: (spam-protected) (Robert Keyes)
Date: Tue, 24 Feb 2009 20:40:29 -0500 (EST)
Subject: [Olsr-users] AHCP
In-Reply-To: <35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com> 
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com> 
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com> 
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
Message-ID: <Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>



On Wed, 25 Feb 2009, Derek C wrote:

> Hi OD,
>
> You mentioned, last month, that you are automatically configuring your
> node's IP addresses based on the MAC address (I think that's what you
> mean).
>
> Would you be able to detail how you do it?  (is it a shell script that
> does it?).
>
> I'm interesting it doing this too if possible to save on having to
> allocate IPs manually - I'm interested to know how you base the IPs on the
> MAC and know that you won't ever have IP duplication.

I don't believe this is possible in IPv4 space. But with a small number of 
nodes, you can make it unlikely that there will be IP duplication.

Considering that most devices of recent manufacture can have their MAC 
address set, it may be better to modify the MAC address to match the IP 
address than the other way around. Doing so also can reduce the IP space 
used, and allow for the use of public IP space. Am I making sense? I can 
give a more detailed explanation if needed.



> thanks,
>
> Derek
>
> On Fri, January 23, 2009 2:40 pm, Outback Dingo wrote:
>> basically a script that runs ipcalc and the mac address of the interface,
>> to create address space
>>
> --
> Derek C
> In Ireland
>
>
>
> -- 
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
>



From (spam-protected)  Wed Feb 25 03:00:22 2009
From: (spam-protected) (Derek C)
Date: Wed, 25 Feb 2009 02:00:22 -0000 (UTC)
Subject: [Olsr-users] AHCP
In-Reply-To: <Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com> 
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com> 
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com> 
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
Message-ID: <34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>

Hi Robert,

I was wondering it is [easily] possible to make a standard firmware that,
once flashed, would start to work without having to modify any settings.

Currently I modify the IP address each and every time after I've flashed
openwrt on to the units.  It would be nice to be able to avoid this as its
work and a point where I'll botch it up :)

I would think you are right about not being able to make a unique IP based
on the MAC with IPV4 - even for a /8 network that would be only three
bytes and three bytes in a MAC are bound to duplicate.

thanks though!,

Derek


--
Derek C
In Ireland





From (spam-protected)  Wed Feb 25 04:19:39 2009
From: (spam-protected) (Outback Dingo)
Date: Wed, 25 Feb 2009 10:19:39 +0700
Subject: [Olsr-users] AHCP
In-Reply-To: <Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com>
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com>
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
Message-ID: <5635aa0d0902241919h279e8991y75aebcfd3b662c25@mail.gmail.com>

Im not quite sure how you figure that as every devices has a unique mac
address
why would one bother to clone a MAC to match an address space, now you have
just made more work. This method does work and id be sure we would need a
mathmatician to prove it wrong, quite simply in a startup script with some
variables
set by setting a base range and using using ipcalc

IP_INT="${INT_PREFIX}.$(hex2dec -c10-11).$(hex2dec -c13-14).$(hex2dec
-c16-17)"

which gives me

config 'interface' 'mesh'
        option 'ifname' 'ath2'
        option 'proto' 'static'
        option 'netmask' '255.0.0.0'
        option 'ipaddr' '5.174.108.95'

config 'interface' 'public'
        option 'ifname' 'ath0'
        option 'proto' 'static'
        option 'netmask' '255.255.255.128'
        option 'ipaddr' '10.108.95.1'

config 'interface' 'private'
        option 'ifname' 'ath1'
        option 'proto' 'static'
        option 'netmask' '255.255.255.192'
        option 'ipaddr' '10.108.95.129'

notice, at least two of the octects in every interface are the same, being
108.95 as derived from the interface MAC

00:15:6D:AD:6C:5F


On Wed, Feb 25, 2009 at 8:40 AM, Robert Keyes <bob at xa.net> wrote:

>
>
> On Wed, 25 Feb 2009, Derek C wrote:
>
>  Hi OD,
>>
>> You mentioned, last month, that you are automatically configuring your
>> node's IP addresses based on the MAC address (I think that's what you
>> mean).
>>
>> Would you be able to detail how you do it?  (is it a shell script that
>> does it?).
>>
>> I'm interesting it doing this too if possible to save on having to
>> allocate IPs manually - I'm interested to know how you base the IPs on the
>> MAC and know that you won't ever have IP duplication.
>>
>
> I don't believe this is possible in IPv4 space. But with a small number of
> nodes, you can make it unlikely that there will be IP duplication.
>
> Considering that most devices of recent manufacture can have their MAC
> address set, it may be better to modify the MAC address to match the IP
> address than the other way around. Doing so also can reduce the IP space
> used, and allow for the use of public IP space. Am I making sense? I can
> give a more detailed explanation if needed.
>
>
>
>  thanks,
>>
>> Derek
>>
>> On Fri, January 23, 2009 2:40 pm, Outback Dingo wrote:
>>
>>> basically a script that runs ipcalc and the mac address of the interface,
>>> to create address space
>>>
>>>  --
>> Derek C
>> In Ireland
>>
>>
>>
>> --
>> Olsr-users mailing list
>> Olsr-users at lists.olsr.org
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/1e74ea90/attachment.html>

From (spam-protected)  Wed Feb 25 04:23:08 2009
From: (spam-protected) (Outback Dingo)
Date: Wed, 25 Feb 2009 10:23:08 +0700
Subject: [Olsr-users] AHCP
In-Reply-To: <34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com>
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com>
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
	<34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
Message-ID: <5635aa0d0902241923s15b174f2jec4679f89836c17a@mail.gmail.com>

Yes, essentailly I have one firmware image i use that autoconfigures every
AP flashed
It doesnt require manuakl configuration, and it it is simply
0-configuration, flash it,
plug it in and go. Ive deployed all my APs using this method, both gateway
nodes and
client (repeater nodes) with 0 issues. Ive done it for olsr, batman,
bmx-advanced and babel

On Wed, Feb 25, 2009 at 9:00 AM, Derek C <derekolsr at hssl.ie> wrote:

> Hi Robert,
>
> I was wondering it is [easily] possible to make a standard firmware that,
> once flashed, would start to work without having to modify any settings.
>
> Currently I modify the IP address each and every time after I've flashed
> openwrt on to the units.  It would be nice to be able to avoid this as its
> work and a point where I'll botch it up :)
>
> I would think you are right about not being able to make a unique IP based
> on the MAC with IPV4 - even for a /8 network that would be only three
> bytes and three bytes in a MAC are bound to duplicate.
>
> thanks though!,
>
> Derek
>
>
> --
> Derek C
> In Ireland
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/6e4b7cd3/attachment.html>

From (spam-protected)  Wed Feb 25 07:56:32 2009
From: (spam-protected) (Antonio Anselmi)
Date: Wed, 25 Feb 2009 07:56:32 +0100 (CET)
Subject: [Olsr-users] AHCP
In-Reply-To: <34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com> 
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com> 
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com> 
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
	<34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
Message-ID: <2075.85.41.146.93.1235544992.squirrel@krisma.oltrelinux.com>

this firmware is already in field: ROBIN open-mesh
(http://www.open-mesh.com)

It's a 0-config firmware builded on top of Openwrt, it offers the
ability to chose batman or olsr, ability to have captive portals
(nodogsplash, chilli, coovaAAA, coova-OM, sputnik,...), dashboard
oriented (it's supported by open-mesh and orange dashboard) and many
other features.

We have tens of thousands nodes deployed and managed directly by
end-users and telco companies.

Firmware is still under heavy development.

Antonio

On Wed, February 25, 2009 3:00, Derek C said:
> Hi Robert,
>
> I was wondering it is [easily] possible to make a standard firmware
> that,
> once flashed, would start to work without having to modify any
> settings.
>
> Currently I modify the IP address each and every time after I've
> flashed
> openwrt on to the units.  It would be nice to be able to avoid this as
> its
> work and a point where I'll botch it up :)
>
> I would think you are right about not being able to make a unique IP
> based
> on the MAC with IPV4 - even for a /8 network that would be only three
> bytes and three bytes in a MAC are bound to duplicate.
>
> thanks though!,
>
> Derek
>
>
> --
> Derek C
> In Ireland
>
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>





From (spam-protected)  Wed Feb 25 08:24:17 2009
From: (spam-protected) (Outback Dingo)
Date: Wed, 25 Feb 2009 14:24:17 +0700
Subject: [Olsr-users] AHCP
In-Reply-To: <2075.85.41.146.93.1235544992.squirrel@krisma.oltrelinux.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com>
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com>
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
	<34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
	<2075.85.41.146.93.1235544992.squirrel@krisma.oltrelinux.com>
Message-ID: <5635aa0d0902242324g2c3fff19v14745e0bf0d07bc@mail.gmail.com>

though lets clarify ROBIN is for atheros based devices so we all know
where this logic should work on broadcom devices also

On Wed, Feb 25, 2009 at 1:56 PM, Antonio Anselmi
<a.anselmi at oltrelinux.com>wrote:

> this firmware is already in field: ROBIN open-mesh
> (http://www.open-mesh.com)
>
> It's a 0-config firmware builded on top of Openwrt, it offers the
> ability to chose batman or olsr, ability to have captive portals
> (nodogsplash, chilli, coovaAAA, coova-OM, sputnik,...), dashboard
> oriented (it's supported by open-mesh and orange dashboard) and many
> other features.
>
> We have tens of thousands nodes deployed and managed directly by
> end-users and telco companies.
>
> Firmware is still under heavy development.
>
> Antonio
>
> On Wed, February 25, 2009 3:00, Derek C said:
> > Hi Robert,
> >
> > I was wondering it is [easily] possible to make a standard firmware
> > that,
> > once flashed, would start to work without having to modify any
> > settings.
> >
> > Currently I modify the IP address each and every time after I've
> > flashed
> > openwrt on to the units.  It would be nice to be able to avoid this as
> > its
> > work and a point where I'll botch it up :)
> >
> > I would think you are right about not being able to make a unique IP
> > based
> > on the MAC with IPV4 - even for a /8 network that would be only three
> > bytes and three bytes in a MAC are bound to duplicate.
> >
> > thanks though!,
> >
> > Derek
> >
> >
> > --
> > Derek C
> > In Ireland
> >
> >
> >
> > --
> > Olsr-users mailing list
> > Olsr-users at lists.olsr.org
> > http://lists.olsr.org/mailman/listinfo/olsr-users
> >
>
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/51a9450b/attachment.html>

From (spam-protected)  Wed Feb 25 08:32:15 2009
From: (spam-protected) (Henning Rogge)
Date: Wed, 25 Feb 2009 08:32:15 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <5635aa0d0902242324g2c3fff19v14745e0bf0d07bc@mail.gmail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<2075.85.41.146.93.1235544992.squirrel@krisma.oltrelinux.com>
	<5635aa0d0902242324g2c3fff19v14745e0bf0d07bc@mail.gmail.com>
Message-ID: <200902250832.20770.rogge@fgan.de>

Am Wednesday 25 February 2009 08:24:17 schrieb Outback Dingo:
> though lets clarify ROBIN is for atheros based devices so we all know
> where this logic should work on broadcom devices also
Limiting the firmware to one producer will limit the range of MAC addresses 
you get, so MAC based IP autoconfig for IPv4 will be easier.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/4fd28e59/attachment.sig>

From (spam-protected)  Wed Feb 25 10:06:59 2009
From: (spam-protected) (ZioPRoTo (Saverio Proto))
Date: Wed, 25 Feb 2009 10:06:59 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com>
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com>
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
	<34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
Message-ID: <a5e23ab90902250106s65247e32ud94f85b155e47162@mail.gmail.com>

> I was wondering it is [easily] possible to make a standard firmware that,
> once flashed, would start to work without having to modify any settings.

Please have a look here : http://blogin.it/

regards

Saverio Proto



From (spam-protected)  Wed Feb 25 10:16:06 2009
From: (spam-protected) (Outback Dingo)
Date: Wed, 25 Feb 2009 16:16:06 +0700
Subject: [Olsr-users] AHCP
In-Reply-To: <200902250832.20770.rogge@fgan.de>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<2075.85.41.146.93.1235544992.squirrel@krisma.oltrelinux.com>
	<5635aa0d0902242324g2c3fff19v14745e0bf0d07bc@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
Message-ID: <5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>

again, i stated Ive done thing on both Atheros and broadcom devices, as in
buffalos/linksys etc, it does also work on atheros
as stated by antonio, ROBIN also works, and is atheros based. Theres are
different works in progress, but this im sure has
gotten a bit offtopic
simply put, if someone wanted to send me a clean functional ahcp config i
could provide an ahcp specifi startup to accomplish this
it really shouldnt matter what brand the router is, as Ive never seen MAC
duplication by vendors. Has anyone ?? Someone flip me a
working configuration to look at.

On Wed, Feb 25, 2009 at 2:32 PM, Henning Rogge <rogge at fgan.de> wrote:

> Am Wednesday 25 February 2009 08:24:17 schrieb Outback Dingo:
> > though lets clarify ROBIN is for atheros based devices so we all know
> > where this logic should work on broadcom devices also
> Limiting the firmware to one producer will limit the range of MAC addresses
> you get, so MAC based IP autoconfig for IPv4 will be easier.
>
> Henning
>
> *************************************************
> Diplom Informatiker Henning Rogge
> Forschungsgesellschaft für
> Angewandte Naturwissenschaften e. V. (FGAN)
> Neuenahrer Str. 20, 53343 Wachtberg, Germany
> Tel.: 0049 (0)228 9435-961
> Fax: 0049 (0)228 9435-685
> E-Mail: rogge at fgan.de
> Web: www.fgan.de
> ************************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
> Joachim Ender (Stellv.)
>
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/3c6cb5de/attachment.html>

From (spam-protected)  Wed Feb 25 10:17:34 2009
From: (spam-protected) (Outback Dingo)
Date: Wed, 25 Feb 2009 16:17:34 +0700
Subject: [Olsr-users] AHCP
In-Reply-To: <a5e23ab90902250106s65247e32ud94f85b155e47162@mail.gmail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<45416.149.5.32.200.1232712105.squirrel@www.rivertowermail.com>
	<5635aa0d0901230434q3c0edfe7off588048a7109257@mail.gmail.com>
	<34479.149.5.32.216.1232721316.squirrel@www.rivertowermail.com>
	<5635aa0d0901230640p38701b9p2cbb1b9d5be0c232@mail.gmail.com>
	<35143.149.5.32.216.1235525211.squirrel@www.rivertowermail.com>
	<Pine.LNX.4.64.0902242034250.27064@neptune.sinister.com>
	<34830.149.5.32.216.1235527222.squirrel@www.rivertowermail.com>
	<a5e23ab90902250106s65247e32ud94f85b155e47162@mail.gmail.com>
Message-ID: <5635aa0d0902250117u28e74adme21e1bbf942c7d62@mail.gmail.com>

someone send me a working configuration for ahcp and i can provide a working
startup routine
for ahcp in general, shouldnt matter the chip type.

On Wed, Feb 25, 2009 at 4:06 PM, ZioPRoTo (Saverio Proto) <
zioproto at gmail.com> wrote:

> > I was wondering it is [easily] possible to make a standard firmware that,
> > once flashed, would start to work without having to modify any settings.
>
> Please have a look here : http://blogin.it/
>
> regards
>
> Saverio Proto
>
> --
> Olsr-users mailing list
> Olsr-users at lists.olsr.org
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/69e451a9/attachment.html>

From (spam-protected)  Wed Feb 25 10:20:42 2009
From: (spam-protected) (Henning Rogge)
Date: Wed, 25 Feb 2009 10:20:42 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
Message-ID: <200902251020.47365.rogge@fgan.de>

Am Wednesday 25 February 2009 10:16:06 schrieb Outback Dingo:
> again, i stated Ive done thing on both Atheros and broadcom devices, as in
> buffalos/linksys etc, it does also work on atheros
> as stated by antonio, ROBIN also works, and is atheros based. Theres are
> different works in progress, but this im sure has
> gotten a bit offtopic
> simply put, if someone wanted to send me a clean functional ahcp config i
> could provide an ahcp specifi startup to accomplish this
> it really shouldnt matter what brand the router is, as Ive never seen MAC
> duplication by vendors. Has anyone ?? Someone flip me a
> working configuration to look at.
If a vendor would produce a colliding MAC he is doing something wrong.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/4f40a69e/attachment.sig>

From (spam-protected)  Wed Feb 25 12:01:09 2009
From: (spam-protected) (Bernd Petrovitsch)
Date: Wed, 25 Feb 2009 12:01:09 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <200902251020.47365.rogge@fgan.de>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de>
Message-ID: <1235559669.22874.27.camel@spike.firmix.at>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/ba9a5c28/attachment.ksh>

From (spam-protected)  Wed Feb 25 14:28:42 2009
From: (spam-protected) (=?ISO-8859-1?Q?Roar_Bj=F8rgum_Rotvik?=)
Date: Wed, 25 Feb 2009 14:28:42 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <200902251020.47365.rogge@fgan.de>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>	<200902250832.20770.rogge@fgan.de>	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de>
Message-ID: <49A5478A.8090401@tihlde.org>

Henning Rogge wrote:
> Am Wednesday 25 February 2009 10:16:06 schrieb Outback Dingo:
[...]
>> it really shouldnt matter what brand the router is, as Ive never seen MAC
>> duplication by vendors. Has anyone ?? Someone flip me a
>> working configuration to look at.
> If a vendor would produce a colliding MAC he is doing something wrong.

I have seen for myself a MAC collision between two Ethernet cards from 
the same vendor. We had problems with traffic on a LAN and after some 
debugging we discovered that two of the cards had the same MAC address.. 
     We needed to change one of the cards to fix things. I don't 
remember the vendor. But it is possible, even if it is very unlikely.

But some causes for duplicate MAC:
1) Bug in provisioning the cards from the manufacturer.
2) Reuse of the MAC address space, as each manufacturer gets a range of 
MAC-addresses and may reuse the MAC addresses when the range is used up. 
How often this happens I don't know.

-- 
Roar Bjørgum Rotvik



From (spam-protected)  Wed Feb 25 14:35:33 2009
From: (spam-protected) (Henning Rogge)
Date: Wed, 25 Feb 2009 14:35:33 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <49A5478A.8090401@tihlde.org>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de> <49A5478A.8090401@tihlde.org>
Message-ID: <200902251435.38150.rogge@fgan.de>

Am Wednesday 25 February 2009 14:28:42 schrieb Roar Bjørgum Rotvik:
> Henning Rogge wrote:
> > Am Wednesday 25 February 2009 10:16:06 schrieb Outback Dingo:
>
> [...]
>
> >> it really shouldnt matter what brand the router is, as Ive never seen
> >> MAC duplication by vendors. Has anyone ?? Someone flip me a
> >> working configuration to look at.
> >
> > If a vendor would produce a colliding MAC he is doing something wrong.
>
> I have seen for myself a MAC collision between two Ethernet cards from
> the same vendor. We had problems with traffic on a LAN and after some
> debugging we discovered that two of the cards had the same MAC address..
>      We needed to change one of the cards to fix things. I don't
> remember the vendor. But it is possible, even if it is very unlikely.
I think that's the reason they put in a 16 Bit random number into the IPv6 
autoconfig.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090225/d3461867/attachment.sig>

From (spam-protected)  Wed Feb 25 15:04:29 2009
From: (spam-protected) (Bernd Petrovitsch)
Date: Wed, 25 Feb 2009 15:04:29 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <49A5478A.8090401@tihlde.org>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de>  <49A5478A.8090401@tihlde.org>
Message-ID: <1235570669.26345.4.camel@spike.firmix.at>

On Wed, 2009-02-25 at 14:28 +0100, Roar Bjørgum Rotvik wrote:
[....]
> But some causes for duplicate MAC:
> 1) Bug in provisioning the cards from the manufacturer.
> 2) Reuse of the MAC address space, as each manufacturer gets a range of 
> MAC-addresses and may reuse the MAC addresses when the range is used up. 
> How often this happens I don't know.
And another data point from a former life:
3) A former company built an embedded system with a serial number chip
   and two onboard ethernet interfaces. Both MAC addresses are generated
   via (different) hash functions out of the serial number at boot time.
   And no, there is no feasible way to guarantee no clashes.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services





From (spam-protected)  Thu Feb 26 22:53:48 2009
From: (spam-protected) (Robert Keyes)
Date: Thu, 26 Feb 2009 16:53:48 -0500 (EST)
Subject: [Olsr-users] AHCP
In-Reply-To: <1235570669.26345.4.camel@spike.firmix.at>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de>  <49A5478A.8090401@tihlde.org>
	<1235570669.26345.4.camel@spike.firmix.at>
Message-ID: <Pine.LNX.4.64.0902261628200.26132@neptune.sinister.com>


Well, it's certainly easy enough to use the MAC address to generate IP 
addresses and it will _probably_ work just fine. But it's not robust. 
Beyond that, there are certain problems with which highest-order octet to 
use. I am pretty sure that there is no one who has a spare 'class A' (a 
/8, in CIDR notation) in publicly-routed IP space which is completely 
spare and can be used for a mesh network. That leaves the possibilities of
either using 'private ip space', as specified in RFC 1918, or breaking 
routing rules and potentially causing a problem by taking a class A and 
using it as private IP space. The only RFC compliant space is 10.0.0.0/8. 
The problem is, this is used by other people in their own internal 
network, behind their NAT. This is why MIT chose to break the routing 
rules and use 5.0.0.0/8 and 6.0.0.0/8 for RoofNet. The problem is these IP 
blocks are owned by Symbolics and Honeywell-Bull, respectively, and if 
these companies ever decide to announce a route to these network 
addresses, or (more likely) the numbers become reassigned to other 
entities who route them, then trouble will arise. But hey? Why think about 
tomorrow or next year or next decade...it works now!

I would expect that after 2011, when we are projected to 'run out' of IPv4 
space, that there will be much reassignment, and reclaiming of large 
blocks of unrouted IP space such as 5 and 6 mentioned above and many 
others. But if you're okay with having to renumber down the road, then go 
ahead and use them.

But say that you want to be able to provide users of your mesh network 
with 'real' publicly routed IP addresses, and not an address behind a NAT. 
There's a bunch of protocols and applications that work better when they 
have a 'real' IP address. I can do this, because I have a class C - 
205.159.169.0/24. If I were to renumber the MAC addresses of the devices 
on my mesh, using an unassigned vendor prefix, I could then assign the 
least significant octet from 1-254 as needed, and align with the IP 
addresses, and thus avoid the use of ARP or hosts tables which is the 
reason for this whole MAC to IP mapping in the first place. Of course, I 
wonder if it wouldn't be more reasonable to continue to use ARP, but set 
the TTL to a high number, such as an hour, to keep the amount of ARP 
traffic on the mesh to a minimum, yet still have the flexibility that ARP 
provides. We could even use DHCP. It could be easy. Maybe ARP needs to 
come back.

What about 802.11s? How is arp going to work with that?



From (spam-protected)  Thu Feb 26 23:10:35 2009
From: (spam-protected) (L. Aaron Kaplan)
Date: Thu, 26 Feb 2009 23:10:35 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <Pine.LNX.4.64.0902261628200.26132@neptune.sinister.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<200902250832.20770.rogge@fgan.de>
	<5635aa0d0902250116q23df684ds1fe4069e70eafaeb@mail.gmail.com>
	<200902251020.47365.rogge@fgan.de> <49A5478A.8090401@tihlde.org>
	<1235570669.26345.4.camel@spike.firmix.at>
	<Pine.LNX.4.64.0902261628200.26132@neptune.sinister.com>
Message-ID: <F589CE62-0930-4CDC-ADFE-8A801C235BA0@lo-res.org>


On Feb 26, 2009, at 10:53 PM, Robert Keyes wrote:

>
> What about 802.11s? How is arp going to work with that?

802.11s comes fixed with 32 IPs. :)

If you go and read the 802.11s specs / drafts you will find that the  
maximum allowable mesh size for 802.11s meshes is 32 nodes.
By definition.

a.




From (spam-protected)  Fri Feb 27 08:11:03 2009
From: (spam-protected) (Henning Rogge)
Date: Fri, 27 Feb 2009 08:11:03 +0100
Subject: [Olsr-users] AHCP
In-Reply-To: <Pine.LNX.4.64.0902261628200.26132@neptune.sinister.com>
References: <560c7c9a0901230244t44f06dcbqcdd7d1ab95a0e8bd@mail.gmail.com>
	<1235570669.26345.4.camel@spike.firmix.at>
	<Pine.LNX.4.64.0902261628200.26132@neptune.sinister.com>
Message-ID: <200902270811.03734.rogge@fgan.de>

Am Thursday 26 February 2009 22:53:48 schrieb Robert Keyes:
> Well, it's certainly easy enough to use the MAC address to generate IP
> addresses and it will _probably_ work just fine. But it's not robust.
> Beyond that, there are certain problems with which highest-order octet to
> use. I am pretty sure that there is no one who has a spare 'class A' (a
> /8, in CIDR notation) in publicly-routed IP space which is completely
> spare and can be used for a mesh network. That leaves the possibilities of
> either using 'private ip space', as specified in RFC 1918, or breaking
> routing rules and potentially causing a problem by taking a class A and
> using it as private IP space. The only RFC compliant space is 10.0.0.0/8.
> The problem is, this is used by other people in their own internal
> network, behind their NAT. This is why MIT chose to break the routing
> rules and use 5.0.0.0/8 and 6.0.0.0/8 for RoofNet. The problem is these IP
> blocks are owned by Symbolics and Honeywell-Bull, respectively, and if
> these companies ever decide to announce a route to these network
> addresses, or (more likely) the numbers become reassigned to other
> entities who route them, then trouble will arise. But hey? Why think about
> tomorrow or next year or next decade...it works now!
IPv6... if we run out of address space there, we will think about the problem 
again.

> I would expect that after 2011, when we are projected to 'run out' of IPv4
> space, that there will be much reassignment, and reclaiming of large
> blocks of unrouted IP space such as 5 and 6 mentioned above and many
> others. But if you're okay with having to renumber down the road, then go
> ahead and use them.
>
> But say that you want to be able to provide users of your mesh network
> with 'real' publicly routed IP addresses, and not an address behind a NAT.
> There's a bunch of protocols and applications that work better when they
> have a 'real' IP address. I can do this, because I have a class C -
> 205.159.169.0/24. If I were to renumber the MAC addresses of the devices
> on my mesh, using an unassigned vendor prefix, I could then assign the
> least significant octet from 1-254 as needed, and align with the IP
> addresses, and thus avoid the use of ARP or hosts tables which is the
> reason for this whole MAC to IP mapping in the first place. Of course, I
> wonder if it wouldn't be more reasonable to continue to use ARP, but set
> the TTL to a high number, such as an hour, to keep the amount of ARP
> traffic on the mesh to a minimum, yet still have the flexibility that ARP
> provides. We could even use DHCP. It could be easy. Maybe ARP needs to
> come back.
We will just switch to IPv6 for OLSR networks. It's not that difficult to 
route IPv4 traffic through IPv6 mesh clouds.

> What about 802.11s? How is arp going to work with that?
802.11s runs on layer 2 with MAC addresses, it does not even know about IP I 
think.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: rogge at fgan.de
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090227/234fcbef/attachment.sig>

From (spam-protected)  Fri Feb 27 09:50:44 2009
From: (spam-protected) (Michael Rack)
Date: Fri, 27 Feb 2009 09:50:44 +0100
Subject: [Olsr-users] Dynamic / Manual route selection in case of bad route
Message-ID: <49A7A964.9030702@rsm-freilassing.de>

Hi List,

i use OLSR to announce my public switched IP-Adresses over 3 
DSL-Connections with different connection-speeds and different 
connection-types.

* First DSL-Connection is wireless connected by 2048 / 2048 kBit.
* Second DSL-Connection is wired SDSL connected by 2048 / 2048 kBit.
* Third DSL-Connection is wired ADSL connected by 4096 / 1024 kBit.

I use OLSR to manage my up- und download-directions with the WEIGHT-Flag 
in the olsrd configuration-file.

Here is my Problem: My first DSL-Connection sometimes have packetloss or 
results in a high roundtriptime. The clients behind my Router can access 
the internet but have a bad connection.

I like to deselect my first DSL-Connection in OLSR to stop routing 
through this device without downtime...

> Interface "bond0" "bond1" "bond2"
> {
>   HelloInterval       2.0
>   HelloValidityTime   6.0
>
>   TcInterval          2.0
>   TcValidityTime      6.0
>
>   MidInterval         2.0
>   MidValidityTime     6.0
>
>   HnaInterval         2.0
>   HnaValidityTime     6.0
> }
>
> Interface "bond0"
> {
>   Weight          1
> }
>
> Interface "bond1"
> {
>   Weight          3
> }
>
> Interface "bond2"
> {
>   Weight          5
> }
My currently solution is to use netfilter and add a rule to drop packets 
on bond0 arrives / sent on port 698. After 6 seconds, my route-table 
changes as expected.

> iptables -A INPUT -i bond0 -p udp --dport 698 -j DROP
> iptables -A OUTPUT -o bond0 -p udp --dport 698 -j DROP

But this is a bad solution?!?

Is there a other way to deselect an interface for routing-reasons, 
without any downtime?

OLSR should check the the interface quality (missing hello-messages, 
triptime of hello-messages) and then select a better interface that have 
the best quality.

I don't like to be a fulltime admin for the manual network-selection.

The B.A.T.M.A.N Project selects the perfect interface by collecting 
informations about the interface quality (missing packages, packet trip 
time and so on).

In final i need "weight" to prefer bond0 for upstream. On the other side 
of the VPN i prefer bond2 for upstream. So i can get 4096kBit download 
over ADSL and 2048kBit upload over Wireless.

regards,
Michael.




From (spam-protected)  Sat Feb 28 11:11:11 2009
From: (spam-protected) (Henning Rogge)
Date: Sat, 28 Feb 2009 11:11:11 +0100
Subject: [Olsr-users] Dynamic / Manual route selection in case of bad
	route
In-Reply-To: <49A7A964.9030702@rsm-freilassing.de>
References: <49A7A964.9030702@rsm-freilassing.de>
Message-ID: <200902281111.15549.hrogge@googlemail.com>

On Freitag 27 Februar 2009 09:50:44 Michael Rack wrote:
> Hi List,
>
> i use OLSR to announce my public switched IP-Adresses over 3
> DSL-Connections with different connection-speeds and different
> connection-types.
>
> * First DSL-Connection is wireless connected by 2048 / 2048 kBit.
> * Second DSL-Connection is wired SDSL connected by 2048 / 2048 kBit.
> * Third DSL-Connection is wired ADSL connected by 4096 / 1024 kBit.
>
> I use OLSR to manage my up- und download-directions with the WEIGHT-Flag
> in the olsrd configuration-file.
Which version of OLSR are you using ?

> Here is my Problem: My first DSL-Connection sometimes have packetloss or
> results in a high roundtriptime. The clients behind my Router can access
> the internet but have a bad connection.
>
> I like to deselect my first DSL-Connection in OLSR to stop routing
> through this device without downtime...
>
> > Interface "bond0" "bond1" "bond2"
> > {
> >   HelloInterval       2.0
> >   HelloValidityTime   6.0
> >
> >   TcInterval          2.0
> >   TcValidityTime      6.0
> >
> >   MidInterval         2.0
> >   MidValidityTime     6.0
> >
> >   HnaInterval         2.0
> >   HnaValidityTime     6.0
> > }
> >
> > Interface "bond0"
> > {
> >   Weight          1
> > }
> >
> > Interface "bond1"
> > {
> >   Weight          3
> > }
> >
> > Interface "bond2"
> > {
> >   Weight          5
> > }
>
> My currently solution is to use netfilter and add a rule to drop packets
> on bond0 arrives / sent on port 698. After 6 seconds, my route-table
> changes as expected.
>
> > iptables -A INPUT -i bond0 -p udp --dport 698 -j DROP
> > iptables -A OUTPUT -o bond0 -p udp --dport 698 -j DROP
>
> But this is a bad solution?!?
so you want to block an OLSR instance from the network without 
killing/restarting the OLSR ? Yes, IpTables might be a good sollution for 
this.

> Is there a other way to deselect an interface for routing-reasons,
> without any downtime?
The problem is that OLSR handles only "OLSR quality". An external traffic will 
not be measured by OLSR itself because HNA Interfaces have no concept of 
"quality" (they just belong to the node which announce the HNA).

> OLSR should check the the interface quality (missing hello-messages,
> triptime of hello-messages) and then select a better interface that have
> the best quality.
>
> I don't like to be a fulltime admin for the manual network-selection.
>
> The B.A.T.M.A.N Project selects the perfect interface by collecting
> informations about the interface quality (missing packages, packet trip
> time and so on).
>
> In final i need "weight" to prefer bond0 for upstream. On the other side
> of the VPN i prefer bond2 for upstream. So i can get 4096kBit download
> over ADSL and 2048kBit upload over Wireless.
I don't think this is possible, especially if you use public-IP space. How 
should the internet should know which interface has the better uplink to your 
network ?

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090228/27199cb6/attachment.sig>