OLSRd GUI front-end

--

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

Re: Olsr-users Digest, Vol 6, Issue 1

> On Wed, 2007-10-31 at 18:49 +0900, David Murray wrote:
> [...]
>> PS: I know this is not the MADWiFi support channel but I have raised
>> this issue with them nobody there seems to have encountered the problem
>
> Do you have an URL to an archive of these threads?
>
> 	Bernd

Sure, I posted a ticket http://madwifi.org/ticket/1530 and have raised 
it in their IRC discussion channel. This should give you the exact 
details of my problem. I suspect that Sven was having the same trouble.

Cheers

Dave

--

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

Re: Olsr-users Digest, Vol 6, Issue 1

--

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

OLSR, fixed networks and MIPv6

--

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

Re: OLSRd GUI front-end

In Don, 2007-11-01 at 16:52 +0800, Florian RODARY wrote:
[...]
> I downloaded the latest version of OLSRd, however, the Linux front-end
> sources don't seem to be included anymore in the package. Is is

Sure?
I can find a olsrd-0.5.4/gui/linux-gtk/ directory.

>  voluntary ? Where I can download them otherwise ?

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

--

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

Active copy of the Links/Routing table

Hi,

I am prototyping some stuff at the moment integrating routing and 
channels. What is the best way of getting an active copy of the routing 
table and links. Basically, I just want the output provided by default 
when you run OLSRD in a form that can be sorted with regular 
expressions. Is this table stored anywhere else other than sent to 
STDOUT?

Thanks

Dave

--

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

Re: Active copy of the Links/Routing table

On Don, 2007-11-08 at 12:18 +0900, David Murray wrote:
[....]
> I am prototyping some stuff at the moment integrating routing and 
> channels. What is the best way of getting an active copy of the routing 
> table and links. Basically, I just want the output provided by default 
> when you run OLSRD in a form that can be sorted with regular 
> expressions. Is this table stored anywhere else other than sent to 
> STDOUT?

Did you look at the output of the txtinfo plugin?
Other than that the usual strategy is to make your own which delivers
what you need in the ways you want (e.g. dot_draw and httpinfo also
produce similar parts for different "applications").
Parsing STDOUT implies lots of used resources inside OLSRD (to generate
the debug output where you throw 80% away).

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

--

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

Scaling of olsr with reduced TTL

Hi all,

we all know that olsrd won't scale with, say 10'000 nodes (or more). Not only 
due to CPU, but also due to the traffic that would cause. I wonder if one 
could still have a working network of such size by simpling reducing the time 
to live (TTL) to say 8 or something. So each node only knows its neighborhood 
up to 8 hops away, but still one does not need to split the network up into 
different wireless cells, that cannot talk to each other peer-to-peer. 

Of course, one could not talk to the nodes far away in the net anymore, but in 
a scenario where a node only needs to communicate with nodes say at most 5 or 
so hops away (because their is a gateway/HNA every few nodes), this might be 
a simple approach to make this work. I do not know the Djikstra algorithm too 
well, hence my question if this would work?

Regards,
Jens

--

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

[Fwd: [Olsr-cvs] olsrd-current/lib/txtinfo/src olsrd_plugin.c, 1.3, 1.4 olsrd_txtinfo.c, 1.14, 1.15]

Since I mailbombed the olsr-cvs <at>  list:
----  snip  -----
Another fat commit:

The main target was:
- Fixed the misleading definition of "v4" in "struct olsr_ip_addr" fom
  "olsr_u32_t" (in network-byteorder!) to "struct in_addr". Lots of
  temporary variables to call inet_ntoa()/inet_ptoa() vanished .....
- declare "int_addr", "int_netmask" and "int_broadaddr" in "struct interface"
  as "struct sockaddr_in" since it is that what we actually want there (and
  it is similar to the IPv6 code).

To get that thoroughly via compiler errors, we get:
- We have now ip4_to_string(), ip6_to_string() and olsr_ip_to_string()
  to print a "struct in_addr", "struct in6_addr" and "union olsr_ip_addr"
  into a string buffer.

Alas, this also annoyed me since ages:
- cleanup: olsr_ip_to_string() and similar non-reentrant functions now must
  get a target buffer. To ease that, there is the "struct ipaddr_str"
  which is large enough for all of them (read: for an IPv6 address). This
  also removes the cyclic buffer there.
  All of these function return a "const char *" which can be directly used
  for printf(3) and friends.

And some cleanups:
- const'ified more functions
- converted the source to UTF-8.
- "struct sig_msg" uses an olsr_u8_t for a byte array (and not "char")
- force the few inline function to always be inlined.
- #ifdef the body of the olsr_print_hna_set() and olsr_print_neighbor_table()
  if nothing is done
- use "inline_avl_comp_ipv4()" in "avl_comp_ipv4()"
- clean up the routes on more signals. Basically we want to do this on all
  signals which terminate the program.
- killed a superflous global buffer in src/main.c

This version was breing since weeks and running for severa day in Vienna's
FunkFeuer net without any noticably problem!

Please report anything that broke!
----  snip  -----
And please any other appropriate feedback!

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

--

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

Re: Scaling of olsr with reduced TTL

> AFAIK there are a few ideas in our heads at the moment: Hannes
> mentioned something with incremental (diffs) of TC messages. This
> should drastically reduce the load.

Yes, such things are very nice and put the "point of not scaling-anymore" into 
farther regions. However, still you would have such a point. I was wondering, 
if such a point at which the network is too large to scale would not exist 
anymore, if just the TTL was not 255 but just something like 8. No artifical 
network splitting necessary, just one wireless network, and every few hops a 
gateway. 

> But what you wrote below sounds very much like HSLS aehh... "fisheye".
> Or did I simply misunderstand you now?

Somewhat like fisheye, just that the max TTL is permanently reduce, say 8 
instead of 255. So a node does not know anything about nodes further away 
than 8 hops. I was just wondering if this works with Djikstra, if the node 
only knows its neighborhood and not the whole topology (assuming the node 
only wants to talk to this neighboorhoud within which might be an HNA)?

Don't think this is brainfuck, throwing out thousands of nodes would be 
nothing for telcos or a government, also not for freenetworks with some 
funding.

jens

> On Nov 8, 2007, at 1:18 PM, Jens Nachtigall wrote:
> > Hi all,
> >
> > we all know that olsrd won't scale with, say 10'000 nodes (or
> > more). Not only
> > due to CPU, but also due to the traffic that would cause. I wonder
> > if one
> > could still have a working network of such size by simpling
> > reducing the time
> > to live (TTL) to say 8 or something. So each node only knows its
> > neighborhood
> > up to 8 hops away, but still one does not need to split the network
> > up into
> > different wireless cells, that cannot talk to each other peer-to-peer.
> >
> > Of course, one could not talk to the nodes far away in the net
> > anymore, but in
> > a scenario where a node only needs to communicate with nodes say at
> > most 5 or
> > so hops away (because their is a gateway/HNA every few nodes), this
> > might be
> > a simple approach to make this work. I do not know the Djikstra
> > algorithm too
> > well, hence my question if this would work?
> >
> >
> > Regards,
> > Jens
> >
> > --
> > Olsr-users mailing list
> > Olsr-users <at> lists.olsr.org
> > http://lists.olsr.org/mailman/listinfo/olsr-users
>
> ---
> there's no place like 127.0.0.1

--

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