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

Thu Mar 28 19:49:11 UTC 2013

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
> 