<div dir="ltr">Responses in-line, <span style="color:rgb(56,118,29)">in green</span> if your email client can do that sort of thing ...<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 9:44 AM, seamus tuohy <span dir="ltr"><<a href="mailto:s2e@opentechinstitute.org" target="_blank">s2e@opentechinstitute.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<div>On 04/02/2013 10:31 AM, Ben West wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">Hi Seamus and Dan,<br>
<br>
</div>
<div class="gmail_extra">Replying about having Python on (and
off) OpenWRT:<br>
</div>
<div class="gmail_extra"><br>
The cross-platform nature seems like it would be very helpful
to maintain a single collection of tests vectors to apply as
Commotion finds its way onto more platforms (Windows, OSX).
But, the obvious tradeoff here is the size of the Python
interpreter.<br>
</div>
</div>
</blockquote>
<br></div>
Agreed!<div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">Also, the test scripts that query a
node's OLSR instance via jsoninfo could also run <i>on the
client</i>, rather than directly on the node. The node
would just need to open up the jsoninfo port 9090 on its
firewall behind the public AP interface (or have the client
use its private AP). I can tweak the Python scripts (tho very
little needed) to accommodate this option.<br>
</div>
</div>
</blockquote>
<br></div>
I think that is a great idea for the openWRT instances. Though, as
we get the other platforms up and running it will be less and less
needed, since we will be running more powerful devices as nodes.<div><br></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">OLSRd will only report details like link quality and routing topology. For lower-level hardware information about the wireless interface, e.g. dBm of remote APs, TX retries, I would highly recommend Henning's fabulous LDEP implementation that is now in the CONFINE repo. That is, the python test script on the client's machine could query data both from the node's OLSRd instance via jsoninfo, and also from its LDEP daemon. And Henning would be thrilled. :)<br>
</span></div><div><span style="color:rgb(56,118,29)"> <br>LDEP implementation targeted at nl80211 for <span class="">OpenWRT</span>:<br><a href="http://wiki.confine-project.eu/soft:dlep" target="_blank">http://wiki.confine-project.eu/soft:dlep</a><br>
<a href="http://wiki.confine-project.eu/soft:confine-dist" target="_blank">http://wiki.confine-project.eu/soft:confine-dist</a><br><a href="https://github.com/confine-project/confine-dist/tree/master/packages/confine" target="_blank">https://github.com/confine-project/confine-dist/tree/master/packages/confine</a> (as packaged into Confine)<br>
<a href="http://olsr.org/git/?p=dlep_app.git;a=tree" target="_blank">http://olsr.org/git/?p=dlep_app.git;a=tree</a> (the current repo?)</span><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Besides that, I think I may be able to
tweak the Python Makefile provided with OpenWRT, so that the
compiled package is much smaller than its current 1.5MByte
footprint. The Python v2.6 implementation bundled into Py4A
(which runs all these tests fine) is <i>only 150kB</i>, by
comparison. Still, admitted that installing another language
on what is already disk- and RAM-bound devices is less than
ideal.<br>
</div>
</div>
</blockquote>
<br></div>
I don't know what the consensus is, but as much as I would love to
start to play with python on the OpenWRT nodes, I think we will be
able to use the existing testing code you built, along with some
client based tweaks to accurately test a OpenWRT based mesh.<div><div><br></div></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">I've so far trimmed the OpenWRT python-mini package down to ~1.2MB, now including unittest. 1.0MByte may be doable with more strenuous weight loss. This package could still be handy to have on hand for reference (i.e. as optional add-on module for Commotion). I will soon share a repo with the modified Makefile</span><br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">Finally, sorry for using the term
'bytecode.' That's not really what we need; compiled Python
bytecode is neither smaller than source nor stand-alone
executable. What I meant is maybe compile the Python
testsuite into a single standalone executable using a tool
like these:<br>
<a href="http://cx-freeze.sourceforge.net/" target="_blank">http://cx-freeze.sourceforge.net/</a><br>
<a href="http://www.pyinstaller.org/" target="_blank">http://www.pyinstaller.org/</a><br>
</div>
<div class="gmail_extra"><br></div></div></blockquote></div></div></div></blockquote><div><span style="color:rgb(56,118,29)">Likewise, if running the Python test suite directly on nodes becomes a necessity, this option to compile those scripts into stand-alone executables is still there. Assume the OpenWRT Makefile-foo required for this is not outrageous.</span><br>
<br></div><br clear="all"></div>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br></div>
</div></div></div>