[Commotion-dev] Merging adhoc tricks...

[Hans of Guardian]

Sounds like quite an elaborate process.  Is there code anywhere else that handles this level of device probing?  My guess is that SPAN has a framework that handles some of it, but I think serval is doing a lot more of this kind of probing and auto-configuring than any other app.

.hc

On Mar 17, 2013, at 3:53 PM, Jeremy Lakeman wrote:

> While working to reduce the importance of root access in Serval Mesh,
> which is more about educating users about our current capabilities
> without root, I've been very tempted to replace all of our adhoc
> control code. Our current process is very convoluted for the things
> it's actually doing.
> 
> This is roughly the current process that Serval uses to find loadable
> wifi modules, which is itself based on the old wifi-tether app. With a
> couple of little tweaks we should implement;
> 
> Turn wifi client on and off through the SDK, compare the list of
> loaded / running modules, look for known wifi module names &
> interfaces.
> 
> If the wifi module has been compiled into the kernel, there's no point
> trying to load it dynamically (eg most google android 4.0+ devices),
> so just skip to configuring the interface and see it that works.
> 
> Look in the filesystem for a dozen or so known modules, firmware blobs
> etc, matching against the above list of loadable modules.
> 
> Not one of those? Start scanning the filesystem;
> - read libhardware_legacy.so looking for module path and parameters,
> check that it matches the detected hardware
> - find all .ko files
> - read the contents of scripts and config files looking for module parameters
> 
> For tiwlan chipsets, find known wlan_loader & firmware paths, copy
> tiwlan.ini and make a couple of changes.
> 
> For broadcom chipsets, copy nvram.txt and make sure the MAC address is
> unique (for huawei ideos), make sure "dhd_pkt_filter_enable=0" is in
> the module parameters or the mesh will be useless when the screen
> turns off.
> 
> Try loading each module found above and attempt to configure the interface.
> 
> If setting adhoc mode fails, you'll probably need a custom kernel.
> 
> If at any time we receive a broadcast Intent indicating that wifi
> client or hotspot failed to start; bring the interface down, unload
> the wifi module and start the operation again.
> 
> On Mon, Mar 18, 2013 at 8:22 AM, Dan Staples
> <danstaples at opentechinstitute.org> wrote:
>> I can confirm that the Samsung Galaxy Nexus does *not* work for Mesh Tether.
>> Though it appears to work with Serval.
>> 
>> Will Hawkins and I were talking about having a discussion soon to plan how
>> to improve Commotion-Android's adhoc support, now that DR1 is out. There has
>> been past discussion on this list about how Mesh Tether, Serval, and SPAN
>> all do ad-hoc differently, and we should figure out concretely how we want
>> to move forward on this. It would be beneficial to get everyone's thoughts
>> and expertise on this planning. Perhaps we can start a separate thread about
>> that, if you think that's needed.
>> 
>> 
>> On 03/17/2013 04:39 PM, Andrew Reynolds wrote:
>> 
>> Thanks for the prod.
>> 
>> The Motorola Atrix 4G on 2.3.6 works consistently.
>> 
>> -andrew
>> 
>> On 03/17/2013 04:01 PM, Ben West wrote:
>> 
>> Hi All,
>> 
>> I've been surfing the listserv archive, and pestering poor Hans, in search
>> of a handset known to be compatible with the Mesh Tether app, and similarly
>> with Serval.  I would like to get such handset myself.
>> 
>> However, since Mesh Tether is known NOT to work with AndroidOS 4.x, I have
>> to locate older, used handsets, adding to the challenge.
>> 
>> Many devices have been reported on this listserv as possibly working.
>> However, I believe Hans clarified that only these devices are known to work
>> fully.
>> 
>>   - HTC Desire running android 2.3
>>   - HTC Wildfire running CyanogenMod 6.1.0
>>   - In general, HTC devices running 2.x (especially the Incredible)
>>   - Google Nexus One (stock 2.3.3), and *NOT* any newer Nexi
>> 
>> In contrast, these devices have been reported to work somewhat, but are
>> expected to be flakey:
>> 
>>   - HTC myTouch 3G (kind of works)
>>   - Samsung Tabs running Android 3.2
>>   - Samsung Galaxy S2
>>   - Samsung Galaxy Player 5.0 running stock 2.3.3 (works only sometimes)
>>   - Motorola Droid/Milestone running CyanogenMod 7 (mostly works)
>> 
>> Hans mentioned that although Samsung handsets appear work, and have been
>> tested to a small extent, they are expected to be quite flakey/unreliable.
>> Likewise, the Samsungs require custom kernels and/or custom kernel options
>> specified at boot, correct?
>> 
>> Please respond to this thread if you have successfully tested a handset,
>> and tested it for reasonable duration of time to ensure no flakiness.  Or,
>> please respond if any of the handset mentioned above is incorrectly listed
>> as working.
>> 
>> Ideally, the responses to this thread can be used to better populate this
>> list on the wiki:
>> 
>> https://code.commotionwireless.net/projects/commotion/wiki/Commotion_Android_Supported_Hardware
>> 
>> 
>> 
>> _______________________________________________
>> 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