[Commotion-dev] Merging adhoc tricks...

Wed Mar 20 20:36:51 UTC 2013

Hello Hans,

We are not aware of any of the other applications performing this kind
of auto-probing and auto-generation of control scripts.  That said, as
devices move to 4.1+ the value probably reduces.  But I think it will
be a while before we can ignore <4.1 devices.

Paul.

On Thu, Mar 21, 2013 at 3:18 AM, Hans of Guardian
<hans at guardianproject.info> wrote:
>
> 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
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev