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

Fri Mar 29 00:58:30 UTC 2013

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