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

Andrew Reynolds andrew at opentechinstitute.org
Thu Mar 28 01:22:59 UTC 2013


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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130327/c573eb80/attachment.sig>


More information about the Commotion-dev mailing list