headers
thomasasta | 1 Jun 2006 19:18
Picon

OLSR vs. FON

Hi

FON.com has grown very much. I think it is the same as OLSR, but only with a commercial aspect. It would be
good, if communities could built each other without central registration and payment to fon.

So I want to see OLSR growing.

Therefore, in a big crowd, we need at least 2 main things: auti-ip-configuration and maybe end-to-end
encryption, that some nodes do not manipulate or control  all the other nodes. No Neighbours logging
please, we had this in the DDR.

Sven-Ola, you said, that you sold the meshing auto-ip dll to a company.
Can you tell me which company this was ? was it meshnode? 

I think the management there needs a turnaround, they want to sell antennas, but they should give the
meshing auto ip configuration DLL free and therefore rename the OLSR protocol to Meshnode-OLSR.

Then the network of free and easy connecting wifi chips will grow and all foneros will be freifunker. In this
context as well antellas and routers could be sold.

Otherwise FON will build up the infrastructure.
We need a switch from fon to freifunk, see the fon webpage, they offers routers for 19 euro and have as well the
maps actualized and already there are in germany for example more foneros than freifunker.

Please be sure to keep this up to date
http://de.wikipedia.org/wiki/OLSR

thanks
--

--
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sven-Ola Tuecke | 2 Jun 2006 10:20
Picon

Re: OLSR vs. FON

Oh... Thomasasta...

I never ever sold and will sell any DLL's with that subject to anybody. As 
pointed out earlier, I am no fan of IP autoconf.

You may try to hand over autonumbering ideas to the mobile/phone industry. 
There are a lot of people who do not want to receive calls. Some of them 
needs those throw-away-mobiles (to get rid of them after the criticical 
application). In this cases, encoding the IMSI into the phone numbers sounds 
like a good idea. No microsoft patents on that topic too ;-) Only 
disadvantage are the long phone numbers. But theres upcoming ENUM as the 
ultimate solution for any number related probs in the world.

P.S.: FON is not a protocol AFAIK. Wrong layer.

Sven-Ola

<thomasasta <at> gmx.net> schrieb im Newsbeitrag 
news:20060601171856.81650 <at> gmx.net...
> Hi
>
> FON.com has grown very much. I think it is the same as OLSR, but only with 
> a commercial aspect. It would be good, if communities could built each 
> other without central registration and payment to fon.
>
> So I want to see OLSR growing.
>
> Therefore, in a big crowd, we need at least 2 main things: 
> auti-ip-configuration and maybe end-to-end encryption, that some nodes do 
> not manipulate or control  all the other nodes. No Neighbours logging
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven-Ola Tuecke | 2 Jun 2006 10:35
Picon

Re: OLSR vs. FON

One more,

in ancient times, there are people that where proud of their names. They 
want to get addressed by others for some funny reason. In that time, when 
two poeple meet, they exchange their names and sometimes numbers.

Old style habits. Today, everyone wants to be autoconfigured. Send in a 
probe of the new-borns to the human genome project to build a hash. Rather 
difficult to identify #25ef5678a on the internet. Yes - privacy protection 
rules. To solve this, simply prevent the need of personal contacts. 
Autoconfigured persons do not need personal contact. Never.

0.02 Euro of
Sven-Ola
Permalink | Reply | 0 comments |
headers
Bernd Petrovitsch | 2 Jun 2006 17:18
Picon
Favicon

Re: OLSR vs. FON

On Thu, 2006-06-01 at 19:18 +0200, thomasasta <at> gmx.net wrote:
[...]
> FON.com has grown very much. I think it is the same as OLSR, but only
                                       ^^^^^^^^^^^^^^^^^^^^^^      ^^^^
>  with a commercial aspect. [...]
  ^^^^^^^^^^^^^^^^^^^^^^^^

Both underlined statements are wrong.

	Bernd
--

-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services
Permalink | Reply | 1 comment |
headers
Luciana Esteves Neves Hilario | 12 Jun 2006 21:22
Picon

OLSR Pocket implementation

Hi everybody!
   Does anybody knows if there is a OLSR implementation version that is RFC
compliant and works OK in Pocket PC with Windows CE?

Thanks for help!

Regards
Luciana
Permalink | Reply | 0 comments |
headers
Rae Harbird | 16 Jun 2006 00:02
Picon
Picon
Favicon

Plugin for dynamic proactive service discovery

Hi

I am developing a service discovery plugin for OLSR. I have integrated 
some java service discovery code that I had already and OLSR by adapting 
the existing nameservice plugin and communicating between the two using 
xmlrpc. It was very successful.

Now I want to dynamically change the behaviour of the routing daemon so 
that it behaves proactively (in an AODV-like way).  Again, I think that 
this will be fairly straightforward but there are some things I'm not 
sure about. I hope you will be able to point me in the right direction 
with some of these points:

(a) Periodic route advertisements will not be needed in proactive mode. 
I'm guessing that deregistering the relevant olsr function from the 
plugin is easy enough. A hint on what to look at would be appreciated.

(b) In proactive mode, service requests will be broadcast from the 
plugin in the usual way through the MPR set (which will equal the 
neighbour set).  Each node will continue to maintain its neighbour set 
so no change needed there.

(c) AODV maintains routes between sources and destinations by recording 
the previous hop and the source from REQuest packets. I don't think OLSR 
messages contain a 'last hop' field so I will need to add one to the 
REQuest messages generated by the plugin. I understand how to register a 
function to process a REQ message when one is received.

(d) I want to be able to send unicast UDP messages for replies, I' m not 
sure what the best way of doing this is. Should it just be some
(Continue reading)

Permalink | Reply | 3 comments |
headers
spoggle | 16 Jun 2006 00:17
Picon

Re: Plugin for dynamic proactive service discovery

I think you have your terminology backwards - OLSR is proactive, AODV
is the opposite, an on-demand protocol (the OD in AODV)

Determining the set of MPRs really requires a proactive protocol.
On-demand protocols are missing the global information that allows the
set of MPRs to be determined.  In special cases it's possible the
information might be available in an on-demand protocol, and it might
be valid, but the reliability of packets passed via the MPRs would be
touchy.  A group that I know of was attempting to provide this sort of
information from an OD protocol, but last I heard it essentially
degenerated into a proactive protocol with all the disadvantages of
both.

If you take away the MPRs, is there any reason why your plugin needs
to be associated with the routing at all?

dave c

On 6/15/06, Rae Harbird <r.harbird <at> cs.ucl.ac.uk> wrote:
> Hi
>
> I am developing a service discovery plugin for OLSR. I have integrated
> some java service discovery code that I had already and OLSR by adapting
> the existing nameservice plugin and communicating between the two using
> xmlrpc. It was very successful.
>
> Now I want to dynamically change the behaviour of the routing daemon so
> that it behaves proactively (in an AODV-like way).  Again, I think that
> this will be fairly straightforward but there are some things I'm not
> sure about. I hope you will be able to point me in the right direction
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rae Harbird | 16 Jun 2006 02:27
Picon
Picon
Favicon

Re: Plugin for dynamic proactive service discovery

spoggle wrote:

> I think you have your terminology backwards - OLSR is proactive, AODV
> is the opposite, an on-demand protocol (the OD in AODV)

Oh sorry! of course - I meant to say reactive, I need to learn a lesson 
about sending messages too late
in the evening.

> Determining the set of MPRs really requires a proactive protocol.

Presume this is because we cannot assume the required level of stability
over a 2-hop span?

> On-demand protocols are missing the global information that allows the
> set of MPRs to be determined.

Because they do not usually maintain neighbour  information through 
HELLO messages?

>   In special cases it's possible the information 

> might be available in an on-demand protocol, and it might
> be valid, but the reliability of packets passed via the MPRs would be
> touchy.

True. Maybe it would be better not to use MPRs in reactive mode.

>   A group that I know of was attempting to provide this sort of
> information from an OD protocol, but last I heard it essentially
(Continue reading)

Permalink | Reply | 1 comment |
headers
spoggle | 16 Jun 2006 02:05
Picon

Re: Plugin for dynamic proactive service discovery

On 6/15/06, Rae Harbird <r.harbird <at> cs.ucl.ac.uk> wrote:
> spoggle wrote:
>
> > I think you have your terminology backwards - OLSR is proactive, AODV
> > is the opposite, an on-demand protocol (the OD in AODV)
>
>
> Oh sorry! of course - I meant to say reactive, I need to learn a lesson
> about sending messages too late
> in the evening.
>
> > Determining the set of MPRs really requires a proactive protocol.
>
> Presume this is because we cannot assume the required level of stability
> over a 2-hop span?
>
> > On-demand protocols are missing the global information that allows the
> > set of MPRs to be determined.
>
> Because they do not usually maintain neighbour  information through
> HELLO messages?

yeah, sort of...

the long answer is that in a proactive protocol i know where each and
every node in the network is and how to get there.  when i go to
determine a set of MPRs, i am guaranteed to have all the topology
information so i won't lose any nodes.

in a reactive protocol, i know where the active nodes are, but if a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Steudtner | 16 Jun 2006 11:36
Picon
Favicon

Implementing an attack into olsrd

Hello,

I wanna implement a blackhole/wormhole into olsrd for my diploma thesis.

A blackhole/wormhole tampers the HELLO-messages he sends out, to tell
all other nodes that it has the best routes to all other nodes. That
means I have to change the code for the HELLO-message generation.

I wonder if it is possible to do that with a plugin or do I have to
change the olsrd code. I also want to have the possibility to switch
between evil and good (with or without blackhole/wormhole) within one node.

Regards,
Holger
Permalink | Reply | 15 comments |

Gmane