[Olsr-dev] Patch Orgy Syncup / Sorting out old TCs [long!]

Aaron Kaplan (spam-protected)
Thu Dec 27 15:00:10 CET 2007


I believe this now is a straight recipe for forks and splits.
In my opinion it would be better to define a main branch (i.e. the hg  
repository now)
and use that as a reference.

So: if I might play friendly dictator once...

   I hereby declare the hg repository to be the main branch

(under the addition that 1) it is written in bold and centered on the  
main olsr.org page
and 2) that there is a transition which syncs the hg repo to CVS on  
sf.net and eventually the CVS repo just follows hg).


I hope this strategy quickly solves any confusion about different  
patch sets , branches or versions.
Otherwise we risk a hell of confusion.


a.


On Dec 27, 2007, at 12:37 PM, Sven-Ola Tuecke wrote:

> Hi,
>
> as posted on our berlin list (german), this may be of interest to  
> others
> too. We currently have 3 main sources of olsr code and it starts to  
> get a
> bit confusing (at least to me). There's the CVS (bit outdated), the  
> HG repo
> from hannes and my patchset for the Freifunk Firmware.
>
> To offer some kind of compromise between stability and actuality  
> (e.g. for
> the 24c3 folks), I placed a Freifunk-variant of the olsr.org daemon  
> sources
> here:
> http://download.berlin.freifunk.net/sven-ola/binaries/
>
> That directory also offers a current Windows OLSRD Installer -  
> which really
> runs smoth now - at least in Berlin... The TGZ is branched from the  
> CVS
> (2007-DEC-14) with all patches applied from here (100 to 139):
> http://download.berlin.freifunk.net/sven-ola/nylon/packages/olsrd/ 
> files/
>
> The same patchset for the *current* CVS is here:
> http://ff-firmware.cvs.sourceforge.net/*checkout*/ff-firmware/ff- 
> devel/patches-rib2.tgz
>
> To document that FYI - here's a patch set description (based on CVS  
> - which
> should stay the major Repo until official change/announced after  
> 0.5.5?):
>
> 100-olsrd-cvs.patch
>   (Diffs from last olsrd-0.5.4.tar.bz2 to current CVS)
> 102-olsrd-windowsfix.patch
>   Changes necessary to compile under Win32/MSVC6
>   Status: Waiting for CVS inclusion
> 103-olsrd-moodfix.patch
>   I have a box with a wrong libc: atof() results in garbage.
>   Status: Not meant for CVS
> 104-olsrd-verysmallfix.patch
>   Discards some debug garbage.
>   Status: Waiting for CVS inclusion
> 105-fix-lq-buffer-quirks.patch
>   Sender side fix for LQHello/LQTC fragmentation.
>   Status: Waiting for CVS inclusion
> 110-bmf-v152.patch
>   Grabbed a copy of eric's plugin and adapted that to CVS
>   Status: Waiting for CVS inclusion
> 115-paa-plugin.patch
>   Experimented a bit with this.
>   Status: Not meant for CVS
> 116-paa-plugin-fix.patch
>
>   PAA plugin makefile breaks make
>   Status: Not meant for CVS, needs rework
> 121-olsrd-fib-metric-approx.patch
>   Adds a new mode for transferring metrics to kernel
>   Status: Waiting for CVS inclusion
> 122-olsrd-lqnatthresh.patch
>   Adds an option to do route damping for the default
>   route. In terms of social costs: It does not matter, if
>   the best gateway is selected when having NAT.
>   It only matters, it the selection is stable for some time.
>   Status: Waiting for CVS inclusion (voodoo. But overall
>   experience is good - no matter who complains)
> 133-fix-lqneigh.patch
>   Reverts an idea of hannes (check seqno < newseqno)
>   because this will lead to not forwarding lqtc if node
>   is restarted a long time.
>   Status: Waiting for CVS inclusion (see below, 134)
> 134-move-tcset-functions-and-revert-parts-of-133.patch
>   Reverts 133 and shift some functions between C sources
>   in order to got a more cleaner 135 patch. I leave that in,
>   because hannes has applied this to his HG repo AFAIK.
>   Status: Waiting for CVS inclusion (see below 135)
> 135-opt-lqtc-seqno.patch
>   A new approach to sort out old LQ-TC messages. Checks
>   ANSN to detect node restarts. If you prefer to read a more
>   clear version, theres a perl script which realizes that with the
>   olsrd's "-dispin" output:
> http://ff-firmware.cvs.sourceforge.net/*checkout*/ff-firmware/ff- 
> devel/contrib/olsr-seqno5.pl
>   Status: Waiting for CVS inclusion
> 136-optimize-invalidip-check.patch
>   Optimize/Corrects the check for invalid IPs
>   Status: Waiting for CVS inclusion
> 137-olsrd-192.168.1.1.patch
>   Adds 192.168.1.1 as invalid-IP (many embedded devices
>   have this addr as default - and it's fatal if sme. can add a
>   host route via OLSR...
>   Status: Not meant for CVS (need cfg file opt for this?)
> 138-optimize-message-generation.patch
>   A multihomed hosts does nameservice announcments with
>   different seqno - which is not necessary because you cannot
>   configure different name-interval for ifaces. Also adds flushing
>   buffer after writing LQ-TC if TC-Interval < Hello-Interval.
>   Status: Waiting for CVS inclusion
> 139-olsrd-magicarprefresh.patch
>   Adds a flag to the add-arp-request because adding tmp-ARP
>   it does not work on linux-2.4.x. You need a patched 2.4.x
>   to make it work. Not needed for linux-2.6.x but it does not
>   hurt <ggg>
>   Status: Waiting for CVS inclusion
> 140-olsrd-optimize-size.patch
>   Discards a lot of debug, hemu sockets, ipc to unbloat
>   Status: Not meant for CVS
> 150-debugtree-sven-ola.patch
>   Adds some kind of traceroute (you need to adapt the
>   IPs in debug_path to your needs, then compile). This is
>   for debugging olsrd only.
>   Status: Not meant for CVS
>
> Some words about the "sorting out old LQ-TCs". Looks good and works  
> (the
> newest topo info is fed into the calculation). But needs further  
> tweaking -
> because it does *not* sort out forwarding old TCs. Mainly, because  
> an old
> to-be-forwarded-TC is already written in the sending buffer while  
> receiving
> a newer TC. Why bother? Because 70-80% of the OLSR traffic is LQ-TC  
> here.
> Which is unnecessary high - all nodes with 135*.patch will sort  
> them out
> anyhow...
>
> // Sven-Ola
>
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>

---
there's no place like 127.0.0.1







More information about the Olsr-dev mailing list