[Commotion-dev] Problem with busybox_config as committed

Thu Jul 26 14:55:49 UTC 2012

On Jul 25, 2012, at 5:38 PM, Will Hawkins wrote:

> Hey Hans! Thanks for your responses. See below.
> 
> On 07/25/2012 11:31 AM, Hans-Christoph Steiner wrote:
>> 
>> Thanks for catching the busybox config issue, I think the thing to try is replace the /usr/local/android-ndk with $NDK_BASE, hopefully that will work.
>> 
> I temporarily committed a note to the documentation to work around this.
> I will look at doing something more permanent based on this information.
> 
>> Whenever you see the can't connect to 9090 error, that means that olsrd is not running. For some reason, the LD_LIBRARY_PATH stopped working for the plugin loading, I dont' know what.  But sticking the full path to the plugins in the olsrd.conf worked for me.  I just pushed that commit.
>> 
>> As for which distro, I think this should work on a lot of android distros.  I've been most recently developing on a Nexus One with the stock ROM.  But HTC+Cyanogenmod is the safest bet.
>> 
> Update: I flashed an HTC Sensation with CM 9 and the app now works ...
> sort of. I occasionally (often, actually) have a problem where the app
> gets stuck at "Found active WAN interface". When this happens it looks
> like the run script doesn't even get to where olsrd is started. If this
> is something you haven't seen, I am happy to debug. I just thought I'd
> ask before I went down that path.

That particular issue doesn't ring a bell, but right now the whole startup/shutdown procedure is a bit fragile.  I was waiting until the unified 'su -c' process stuff was done before smoothing out the starutp/shutdown.

>> There is one other relevant outstanding issue: the routing.  The Android static IP API requires that a gateway is specified.  So we stuck in the phone's own IP for the gateway.  This means the default route is then the phones own IP.  I added busybox so we can easily delete that route, but I haven't found the right place in the whole startup operation to do this and actually have the setting stick.  It can be done manually and it works.
>> 
>> So this just means that an HNA that specifies a default route (0.0.0.0) won't work in the current app without manual intervention via the terminal.  Once we have Will's framework for starting and stopping lots of terminal command via a single 'su -c' thread, then we can clean up the whole startup process and make sure that route stays deleted.
>> 
> This is something that I think I've run into. However, I may actually
> have been running into a different issue.
> 
> In either case, I have been pulled to another task this week so my work
> on the single-shell tool has been postponed. I should be able to restart
> that work early next week and I hope to have something by the middle of
> next week.

Ok, thanks for keeping me posted.

.hc

> 
> Will
> 
>> .hc
>> 
>> On Jul 24, 2012, at 7:57 PM, Will Hawkins wrote:
>> 
>>> Hey Hans!
>>> 
>>> I know that you're out of town, so I hate to bother you. I am trying to
>>> work through the latest commits. It appears that the app "does not work"
>>> on any of the phones that we've tested here.
>>> 
>>> We are using the HTC Sensation 4G, the Virgin Mobile LG phone and
>>> Andrew's Motorola Atrix device.
>>> 
>>> The most visible error that we see is that the app cannot connect to the
>>> JsonInfo plugin on port 9090. This seems to be a red herring, though. On
>>> the devices, the wifi never really seems to associate. Given the changes
>>> that have been made to how you are now associating with access points, I
>>> don't know what other helpful information to provide for your debugging.
>>> 
>>> If there are things that you want me to try, please let me know.
>>> Otherwise, I will continue to debug on my own and sync up when you are
>>> back around.
>>> 
>>> Talk to you soon!
>>> Will
>>> 
>>> On 07/24/2012 12:32 PM, Will Hawkins wrote:
>>>> Hey Hans!
>>>> 
>>>> We were having trouble building busybox, so I investigated the
>>>> busybox_config file. It looks like there is a hard-coded path set in
>>>> CONFIG_SYSROOT that prevents it from building when the NDK is not in a
>>>> particular location.
>>>> 
>>>> After I modified the CONFIG_SYSROOT value to reflect the location of the
>>>> system root in my NDK installation, everything worked fine. Is there a
>>>> way that I can make that variable dynamic? Or should I just add a note
>>>> to the README saying that it needs to be changed as part of the build
>>>> process?
>>>> 
>>>> Thanks as always!
>>>> Will
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>> 
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>> 
>> 
>> 