[Commotion-dev] Can't talk between desktop OLSRd and Commotion OpenWRT boxes

Fri Mar 29 18:12:33 UTC 2013

I'll also add that the olsrd devs can be grumpy, but I think they all want to
see this kind of consolidation work done, so don't let the grumpiness dissuade
you!

.hc

On 03/28/2013 05:58 PM, Dan Staples wrote:
> That's a good point, Hans. I'll email the olsrd dev list tomorrow to 
> try to get a handle on what the end product would be and how much work 
> that might take. That will help us judge if it's a suitable task for us 
> to take on, given our roadmap for core Commotion development.
> 
> On Thu 28 Mar 2013 03:49:11 PM EDT, Hans-Christoph Steiner wrote:
>>
>> What olsrd needs is someone with the resources to merge the various parallel
>> efforts of mDNS/DNSSD.  It would be a chunk of work, like Dan said, but it
>> will benefit everyone if those efforts are merged because maintenance, new
>> features, bug fixes, testing, etc. would all be shared.  I think it would be
>> very worthwhile for OTI to take it on since it is the best way to guarantee
>> the long term maintenance of that code.
>>
>> .hc
>>
>> On 03/28/2013 09:49 AM, Dan Staples wrote:
>>> The OLSRd dev folks weren't interested in the DNSSD plugin, unless
>>> someone does a merge of all the different existing multicast plugins.
>>> That's not something I'm interested in doing, and would be a significant
>>> effort for anyone not already versed in the existing plugins. So I doubt
>>> DNSSD will ever make it into upstream olsrd. Will said there was also a
>>> lack of interest in the MDP plugin he wrote, so that will also not
>>> likely make it upstream. However, we need those plugins for any
>>> Commotion nodes that want to be compatible with DR1.
>>>
>>> If the point of the Guardian PPA is to get a hardened olsrd version into
>>> Debian, then I don't think it would be appropriate to include our
>>> plugins in it, since they are not "official" olsrd plugins. But if the
>>> goal is to have a Commotion-compatible PPA of olsrd, then it would make
>>> sense to include our plugins.
>>>
>>> Dan
>>>
>>> On 03/28/2013 11:54 AM, Andrew Reynolds wrote:
>>>> Agreed.
>>>>
>>>> On that note, commotion and olsr devs, where do we currently diverge,
>>>> and what are the barriers to integration?
>>>>
>>>> I'm aware of the following:
>>>> New olsrd plugins used in commotion DR1 (MDP, DNSSD): OLSR community had
>>>> concerns about plugin duplication. Commotion community willing to merge
>>>> in order to integrate upstream. Dan, is time the main obstacle here or
>>>> do we need more input on how best to proceed?
>>>>
>>>> New bugfix referenced below: Has this been incorporated in the Commotion
>>>> fork or only in Guardian's PPA? Have the patches been submitted to OLSR?
>>>>
>>>> Hardening patches: It sounds like this is in process.
>>>>
>>>> It also sounds like we now have two forks (the one we use in
>>>> Commotion-OpenWRT DR1 and the one Hans is using on his PPA). If we
>>>> haven't already, can we either standardize across our repos while we
>>>> work on upstream integration or push the development features to our
>>>> fork so Hans can focus on debian inclusion with the PPA? I'm not sure
>>>> which would be more beneficial.
>>>>
>>>> -andrew
>>>>
>>>> On 03/28/2013 11:20 AM, Teco Boot wrote:
>>>>> All,
>>>>>
>>>>> I did see some bad things happened in the past, where improvements on
>>>>> olsrd were not published upstream and were lost. Some of it: link
>>>>> metrics and fix for MPR flooding. So I strongly recommend new work on
>>>>> olsrd is kept on its home base.
>>>>>
>>>>> Teco
>>>>>
>>>>>
>>>>> Op 28 mrt. 2013, om 02:22 heeft Andrew Reynolds
>>>>> <andrew at opentechinstitute.org> het volgende geschreven:
>>>>>
>>>>>> We had been talking about starting up an OTI PPA earlier this
>>>>>> morning. One of our newer members is really interested in taking
>>>>>> that on. I had meant to ping you about it (among other things) but
>>>>>> got bogged down in meetings.
>>>>>>
>>>>>> While I do want to keep our stable and experimental packages
>>>>>> separate, we will need to begin porting the new DR1 features
>>>>>> (including the OLSR plugins) over to the non-router platforms.
>>>>>>
>>>>>> For what it's worth, here is the target feature list for DR1
>>>>>> (https://code.commotionwireless.net/versions/2), and the beginnings
>>>>>> of the architecture document for the new features as they relate to
>>>>>> OpenWRT
>>>>>> (https://code.commotionwireless.net/projects/commotion/wiki/Commotion_Architecture).
>>>>>>
>>>>>>
>>>> Now that the dust has begun to settle from the initial rollout, we will
>>>>>> begin incorporating our notes into the main documentation.
>>>>>>
>>>>>> As for using and maintaining a fork of OLSRd, we would ultimately
>>>>>> prefer to incorporate any fixes and plugins upstream instead of
>>>>>> maintaining a fork. Until the outstanding questions around
>>>>>> incorporation are addressed, it seems reasonable to point to our
>>>>>> fork. That doesn't address OLSR's inclusion in debian, but I can't
>>>>>> see a near-future situation in which Commotion won't need to point
>>>>>> to a newer version of OLSRd than debian provides. Am I wrong in
>>>>>> thinking these are almost separate issues?
>>>>>>
>>>>>> -andrew
>>>>>>
>>>>>> On 03/27/2013 07:28 PM, Hans-Christoph Steiner wrote:
>>>>>>> Yes, I added some of the Debian hardening stuff to that package.
>>>>>>> Some of that hardening stuff was included upstream and is
>>>>>>> therefore in v0.6.5.2 already, but not all was included yet.
>>>>>>>
>>>>>>> I don't know those plugins, so I don't know if they'd be useful.
>>>>>>> At this point, I think the guardianproject/commotion PPA should
>>>>>>> be focused on providing a "stable" build so that when people try
>>>>>>> it, they are most likely to get some kind of working mesh.  As
>>>>>>> far as I have heard, this client is focused on end users rather
>>>>>>> than backhaul providers, so I haven't looked at the backhaul
>>>>>>> stuff at all.
>>>>>>>
>>>>>>> How about starting an official OTI PPA and uploading the DR1
>>>>>>> olsrd v0.6.5.2 there?  Ultimately, I think it'll be good to have
>>>>>>> these packages in an "official" OTI PPA anyway.  I can set that
>>>>>>> up if you want, I've set up a few PPAs on launchpad.
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>> On 03/27/2013 04:07 PM, Dan Staples wrote:
>>>>>>>> If I remember correctly, your PPA provides a hardened version
>>>>>>>> of olsrd, yes?
>>>>>>>>
>>>>>>>> For our DR1 release of Commotion-OpenWRT, we're using a custom
>>>>>>>> version of olsrd v0.6.5.2 with our own dnssd and mdp plugins.
>>>>>>>> It's what we have in the OTI github repo. Do you think it would
>>>>>>>> be useful to use that version? DR1 meshes that have backhaul
>>>>>>>> security turned on would only be able to talk to other nodes
>>>>>>>> running olsrd w/ the mdp plugin enabled.
>>>>>>>>
>>>>>>>> On Wed 27 Mar 2013 06:08:48 PM EDT, Hans-Christoph Steiner
>>>>>>>> wrote:
>>>>>>>>> I pushed an update to the olsrd package to our Commotion PPA,
>>>>>>>>> they should be built in about 5 hours.  The only change was
>>>>>>>>> including the commit that should fix this issue.
>>>>>>>>>
>>>>>>>>> If the OTI crew thinks that we should be using a newer
>>>>>>>>> version of olsrd, I can update the package there.  Right now,
>>>>>>>>> I'm just keeping it in sync with the effort to get an update
>>>>>>>>> into Debian/wheezy.
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>> On 03/26/2013 10:23 AM, Will Hawkins wrote:
>>>>>>>>>> Sorry it's taken me so long to pipe up on this thread. I
>>>>>>>>>> looked at that patch that Ben/HC referenced. The fix that
>>>>>>>>>> they applied definitely fixes a problem. And, based on
>>>>>>>>>> Ben's testing, it seems like it is the problem.
>>>>>>>>>>
>>>>>>>>>> From my reading, the way the code was written, it was
>>>>>>>>>> working without this patch only by chance. So, definitely a
>>>>>>>>>> good one to include :-)
>>>>>>>>>>
>>>>>>>>>> Will
>>>>>>>>>>
>>>>>>>>>> On 03/19/2013 02:13 AM, Ben West wrote:
>>>>>>>>>>> I have been able to get a custom-compiled olsrd running
>>>>>>>>>>> now under my own instances of Ubuntu quantal, by applying
>>>>>>>>>>> this patch to src/net_olsr.c and then rebuilding the
>>>>>>>>>>> debs:
>>>>>>>>>>> https://lists.olsr.org/pipermail/olsr-dev/2012-June/005547.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> This patch was referred to in the thread started by Hans on this topic
>>>>>>>>>>> in the olsr-dev listserv:
>>>>>>>>>>> https://lists.olsr.org/pipermail/olsr-dev/2013-March/006725.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> Interestingly, the original bug was basically that olsrd was not sending
>>>>>>>>>>> outgoing packets out the wireless interface, instead
>>>>>>>>>>> failing with error message "sendto(v4): Invalid
>>>>>>>>>>> argument."  The variables that are supposed to store the
>>>>>>>>>>> destination address for IPv4/6 packets, due to improper
>>>>>>>>>>> declaration, were being sometimes optimized away,
>>>>>>>>>>> depending on the gcc version and the optimization flags
>>>>>>>>>>> given.  The patch mentioned above corrects the variables'
>>>>>>>>>>> declaration.
>>>>>>>>>>>
>>>>>>>>>>> It seems this particular bug has been fixed in newer
>>>>>>>>>>> versions of olsrd, but I'm guessing Canonical isn't going
>>>>>>>>>>> to be especially prompt about releasing an updated Ubuntu
>>>>>>>>>>> package.
>>>>>>>>>>>
>>>>>>>>>>> Could this patch be included in the guardianproject PPA
>>>>>>>>>>> for olsrd?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 18, 2013 at 2:38 PM, Ben West
>>>>>>>>>>> <ben at gowasabi.net <mailto:ben at gowasabi.net>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> I'm having difficulty replicating this solution on my own
>>>>>>>>>>> platform (Ubuntu quantal i386 under a VMware host, but
>>>>>>>>>>> with real USB wifi radio).
>>>>>>>>>>>
>>>>>>>>>>> That is, removing the O2 compile option and recompiling
>>>>>>>>>>> olsrd does not seem to yield a working olsrd for me.  I'm
>>>>>>>>>>> presently trying this out on a real host instead (i.e. no
>>>>>>>>>>> virtualization), but that is slowly opening a delightful
>>>>>>>>>>> can of worms w/r/t/ to thge newer Ubuntus dropping legacy
>>>>>>>>>>> video driver support and other such pleasantness.
>>>>>>>>>>>
>>>>>>>>>>> If the problem's source has been conclusively narrowed
>>>>>>>>>>> down to the -O2 (and even -fPIE?) flag added by Hans'
>>>>>>>>>>> patch 310-hardening-fixes.patch, could Hans just release
>>>>>>>>>>> an updated olsrd package in his PPA, with those flags
>>>>>>>>>>> removed, as an interim workaround for anyone not able to
>>>>>>>>>>> compile their own?
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Mar 9, 2013 at 12:34 PM, Mikael Nordfeldth
>>>>>>>>>>> <mmn at hethane.se <mailto:mmn at hethane.se>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 2013-03-08 19:27, Hans-Christoph Steiner skrev:
>>>>>>>>>>>> That would be quite useful if you have the time!
>>>>>>>>>>>> Another
>>>>>>>>>>> thing that might the
>>>>>>>>>>>> whole process easier is to 'git bisect', if you are
>>>>>>>>>>>> familiar
>>>>>>>>>>> with that..
>>>>>>>>>>>> Right now, Debian squeeze and wheezy have 0.6.2, and
>>>>>>>>>>>> Ubuntu
>>>>>>>>>>> has 0.6.1 and 0.6.3:
>>>>>>>>>>>> http://packages.debian.org/search?keywords=olsrd
>>>>>>>>>>>> http://packages.ubuntu.com/search?keywords=olsrd
>>>>>>>>>>>>
>>>>>>>>>>>> So the idea is to find out which version of these we
>>>>>>>>>>>> can rely
>>>>>>>>>>> on, and which we
>>>>>>>>>>>> need to use replacements.
>>>>>>>>>>> Gah. This seems way more advanced than what I can explain
>>>>>>>>>>> with my knowledge. Nevertheless, I did find what caused
>>>>>>>>>>> my error, the -O2 gcc optimization switch as patched by
>>>>>>>>>>> Debian package "hardening fixes":
>>>>>>>>>>>
>>>>>>>>>>> 1. I tried compiling various olsrd versions. All worked.
>>>>>>>>>>> 2. I tried compiling 0.6.3-5~quantal from 'apt-get
>>>>>>>>>>> source'. It didn't work. 3. I tried compiling the
>>>>>>>>>>> 0.6.3.orig source (same as above, without debian patches)
>>>>>>>>>>> It worked. 4. None of the patches contained any
>>>>>>>>>>> networking code (except the json plugin, but disabling it
>>>>>>>>>>> didn't have any effect anyway) 5. I found that removing
>>>>>>>>>>> the -O2 switch on line 227 in Makefile.inc, as patched by
>>>>>>>>>>> 310-hardening-fixes.patch resolved my invalid argument
>>>>>>>>>>> sendto(v4) issue:
>>>>>>>>>>>
>>>>>>>>>>> %.o: %.c @echo "[CC] $<" -       $(CC) $(CFLAGS)
>>>>>>>>>>> $(CPPFLAGS) -c -o $@ $< +       $(CC) -O2 $(CFLAGS)
>>>>>>>>>>> $(CPPFLAGS) -fPIE -c -o $@ $<
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Reverting this (and even leaving the -fPIE there but
>>>>>>>>>>> removing -O2) makes the resulting binary functional.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So the specific problem was caused by the -O2 parameter
>>>>>>>>>>> to gcc, I guess making it a compiling/linking issue. I
>>>>>>>>>>> don't know enough about this myself though, so I'm
>>>>>>>>>>> attaching ('O2-opts') the output of what that level of
>>>>>>>>>>> optimizations means if anyone is interested (gcc -c -Q
>>>>>>>>>>> -O2 --help=optimizers)
>>>>>>>>>>>
>>>>>>>>>>> More info on my build environment is below:
>>>>>>>>>>>
>>>>>>>>>>> $ gcc -v Using built-in specs. COLLECT_GCC=gcc
>>>>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
>>>>>>>>>>>
>>>>>>>>>>>
>>>> Target: x86_64-linux-gnu
>>>>>>>>>>> Configured with: ../src/configure -v
>>>>>>>>>>> --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1'
>>>>>>>>>>> --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
>>>>>>>>>>> --enable-languages=c,c++,go,fortran,objc,obj-c++
>>>>>>>>>>> --prefix=/usr --program-suffix=-4.7 --enable-shared
>>>>>>>>>>> --enable-linker-build-id --with-system-zlib
>>>>>>>>>>> --libexecdir=/usr/lib --without-included-gettext
>>>>>>>>>>> --enable-threads=posix
>>>>>>>>>>> --with-gxx-include-dir=/usr/include/c++/4.7
>>>>>>>>>>> --libdir=/usr/lib --enable-nls --with-sysroot=/
>>>>>>>>>>> --enable-clocale=gnu --enable-libstdcxx-debug
>>>>>>>>>>> --enable-libstdcxx-time=yes --enable-gnu-unique-object
>>>>>>>>>>> --enable-plugin --enable-objc-gc --disable-werror
>>>>>>>>>>> --with-arch-32=i686 --with-tune=generic
>>>>>>>>>>> --enable-checking=release --build=x86_64-linux-gnu
>>>>>>>>>>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread
>>>>>>>>>>> model: posix gcc version 4.7.2 (Ubuntu/Linaro
>>>>>>>>>>> 4.7.2-2ubuntu1)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> $ uname -a Linux plexi 3.5.0-25-generic #39-Ubuntu SMP
>>>>>>>>>>> Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64
>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Commotion-dev mailing list
>>>>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>>>>> <mailto:Commotion-dev at lists.chambana.net>
>>>>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> --
>>>>>>>>>>> Ben West http://gowasabi.net ben at gowasabi.net
>>>>>>>>>>> <mailto:ben at gowasabi.net> 314-246-9434
>>>>>>>>>>> <tel:314-246-9434>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- Ben West http://gowasabi.net ben at gowasabi.net
>>>>>>>>>>> <mailto:ben at gowasabi.net> 314-246-9434
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Commotion-dev mailing list
>>>>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>>>>
>>>> _______________________________________________
>>>>>>>>>> Commotion-dev mailing list
>>>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________ Commotion-dev
>>>>>>>>> mailing list Commotion-dev at lists.chambana.net
>>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>> -- Dan Staples
>>>>>>>>
>>>>>>>> Open Technology Institute https://commotionwireless.net
>>>>>>>> _______________________________________________ Commotion-dev
>>>>>>>> mailing list Commotion-dev at lists.chambana.net
>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>
>>>>>>> _______________________________________________ Commotion-dev
>>>>>>> mailing list Commotion-dev at lists.chambana.net
>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ Commotion-dev
>>>>>> mailing list Commotion-dev at lists.chambana.net
>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>> _______________________________________________ Commotion-dev mailing
>>>>> list Commotion-dev at lists.chambana.net
>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
> 
> --
> Dan Staples
> 
> Open Technology Institute
> https://commotionwireless.net
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
> 