[Commotion-dev] Merging adhoc tricks...

[Jeremy Lakeman]

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
>