1 Oct 2007 07:49
Re: Freifunk mesh set up
Sven-Ola Tuecke <mail2news <at> commando.de>
2007-10-01 05:49:03 GMT
2007-10-01 05:49:03 GMT
Morning, that little howto suggests using 104.x.x.x adresses. Thats not wrong but has a small disadvantage: They may be used in the internet one day. We use 104.x.x.x in Berlin for historic reasons and too many node owners to convince so that IP allocation will stay in force. But I always recommend using other IPs for a new mesh, e.g. 10.x.x.x. You know the ping command - that's fine <ggg>. To be honest: there are plenty of pitfalls you may stumble across. Look at the admin page (the page displayed if you click on the top "admin" link. All entries should show a green OK sign. The OLSR-DHCP function only does it's job, if you installed the "freifunk-recommended-en" package. For a first-timer, I would not recommend using this, because most newbies do not understand the underlying IP calculation. They do not understand the output of the "ipcalc" command and this alone leads to a lot confusion). Also: DHCP attracts brain-dead software and users in the neighbourhood - which may or not may be your intention. Simply attach a notebook to one of the LAN ports instead. Yes: this requires the blue cable <ggg> Do *not* change the local LAN IP address. This should stay "static" and 192.168.1.1 with 255.255.255.0. Do not try to set a manual default route. Check the status page: Is the other WRT is in the neighbours list? Also check the wireless status on the status page. All fine? P.S.: If you cannot connect nor ping, I will need more info. Grab a PuTTY, connect to one of the WRTs using SSH. Then enter these commands, cut-copy the output to clipboard and send it along with your next query (if(Continue reading)
.
Major changes to 0.5.4rc1:
- from Sven-Ola Tücke: Do not forward packets with too low TTL (e.g.
TTL == 0). This was in since ages and seems to be the reason for
packet storms (using - at least - unnecessary bandwith and CPU power).
- from Hannes Gredler (together with Sven-Ola Tücke): Fixed a bug after
changing (or downing and upping the interface with the main address)
the IP address.
Thanks to all sending patches improving here and there major and minor
issues, using, testing and reporting - especially for the non-Linux-IPv4
parts and even more the things I break (like on *BSD).
If you think I forgot your patch, it is probably the case or the patch
was not against CVS-HEAD or 0.5.4rc1 (so I couldn't easily test it at
home). So please rebase it and send it over again (and maybe write
explicitly if it's intended for inclusion or not). Do not hesitate to
ask if rebasing is not that trivial - *eg* Hannes is hopefully around to
answer questions on the not-so-trivial changes.
E.g. I have one right now: If I walk through the routingtable with
"OLSR_FOR_ALL_RT_ENTRIES()", how do I distinguish HNA-announced routes
from OLSR-learned routes?
The full changelog (against 0.5.3) is:
---- snip ----
QUAGGA by Immo 'FaUl' Wehrenberg <immo.olsr <at> do.bundessicherheitsministerium.de>
- updated to svn version 33
BMF PLUGIN by Erik Tromp <erik_tromp <at> hotmail.com>
- updated to 1.5.1
- updated to latest plugin interfaces changes and killed warnings (by Bernd
Petrovitsch <bernd <at> firmix.at>)
PATCH by Hannes Gredler <hannes <at> gredler.at> which rewrites the route handling.
To quote him:
---- snip ----
change list:
- get rid of separate routing tables for HNA and per-node routes, everything is
now unified in an AVL routing tree (&routingtree)
- introduce walking macros (OLSR_FOR_ALL_RT_ENTRIES()) that hide the internal
structure of the RIB for making life of the plugin authors easier.
- get rid of different SPF implementations for LQ and non-LQ code paths. a
non-LQ edge is simply substituted with a cost of 1.0
- get rid of host masks - a new data type olsr_prefix is introduced which is
basically an ip address plus a prefix length.
do not install the metric in the kernel FIB - for the kernel its pointless
if the route gets installed with a metric of N or M.
we do not need to update the kernel FIB if we have hop count only changes
(for example if there is a reroute action further downstream)
the only things which triggers a kernel FIB route update is a next hop
change (a next hop is neighboring gateway router plus an interface).
all OLSR routes are installed with a metric of 2
- separate between rt_entry and rt_path - the former is a route installed in the
kernel with an next hop. the latter is a candidate for best path selection
after SPF calculation has been done. in the rt_entry we keep a pointer to the
best_path and also to the next hop that was installed in the kernel FIB.
we always keep all originator of a route, if a route originator goes away we
can easy recompute the best path for the route.
the next hop in the rt_entry gets only updated upon a successful route_add
call - that way we always remember what next hop to delete.
stray routes should be history now.
- tweak the linked list toolkit to operate on circular lists.
- get rid of malloc calls for building the kernel update list. the list node is
now embedded in the rt_entry.
- introduce three queues (add/chg/del) for kernel updates.
- for neighbor route dependency tracking the neighbor routes are queued first or
last (depending on which queue you work on)
- rework all the plugins which directly manipulate rt entries.
- rework the plugins that read from the routing table (most notably nameserver,
httpinfo and quagga plugin)
- lots of comments that explains the intentions and purpose of this code-piece.
non RT related stuff:
- use a list rather than a tree for storing the post-SPF results, which further
improves the raw-SPF runtime.
- add display of SPF runtime (masked behind #ifdef SPF_PROFILING)
- 
RSS Feed