[Commotion-dev] Can't talk between desktop OLSRd and Commotion OpenWRT boxes
Teco Boot
teco at inf-net.nl
Thu Mar 28 15:20:04 UTC 2013
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
More information about the Commotion-dev
mailing list