[Commotion-dev] Submitted DNS and configuration changes

Will Hawkins hawkinsw at opentechinstitute.org
Fri May 11 15:05:33 UTC 2012


On 05/11/2012 10:37 AM, Hans-Christoph Steiner wrote:
> 
> On May 11, 2012, at 10:21 AM, Will Hawkins wrote:
> 
>> On 05/10/2012 09:06 PM, Hans-Christoph Steiner wrote:
>>>
>>> I looked thru your pull request. I have a couple comments:
>>>
>>> * why do you set the DNS via setprop?  Ideally there would be an Android Java API to do this.  I find that messing with things on the terminal level can cause weirdness in apps because the Android level gets out of sync with the lower level.  Here's an example we have to work on: turning off the wifi via Android/Java then enabling it via the shell script causes Android to think that there is no net connection.  Many apps rely on Android to tell them whether there is an net connection, so in mesh mode, these apps will think there is no net connectivitiy because that's what Android believes.
>>>
>> There is an API to the properties and I initially tried to use that to
>> set the net.dns1 property. Unfortunately, because Android considers
>> net.dns1 to be a "System" property, the Java API does not allow it to be
>> read or set by normal user application. There is a list of the
>> properties accessible via the API at
>> http://developer.android.com/reference/java/lang/System.html#getProperty%28java.lang.String%29
>>
>>
>> As someone who never believes what they read, I tried it myself. No
>> luck. I had to resort to the ash script to get it to do what I wanted.
> 
> If there really is no other way to solve this problem, or its just a temporary measure, then I'm fine with this.  But I think we should try to avoid non-standard, private APIs as much as possible.  I am guessing that Android doesn't let you change this via Java because it can't guarantee that it'll always use the user-supplied setting.
> 
> I think we'll have to figure this out along with the issues related to disabling wifi in Java and enabling it via our own util (i.e. the wifi binary).
> 

I certainly agree that doing things "privately" is not the best way to
do it. I will continue to look for ways to make changes to the
system-wide DNS server settings through a Java API. Until then, I
suppose this method will work.

I'm sure you saw this, but I wanted to point it out: I capture the value
of net.dns1 before replacing it. I reset net.dns1 to the captured value
as soon as the user disconnects from the mesh. That seems to minimize
the surprise to the user.

>>> * any reason to leave brncl_lan_gw and brncl_lan_netmask variables around?  I say delete unused variables
>>
>> brncl_lan_gw and brncl_lan_netmask are required by the wifi binary
>> (main.cc). I didn't know if our project has "control" over that source
>> code so I maintained those variables for compatibility. If there is no
>> issue modifying the wifi source code, then I can change those variable
>> references and get rid of unused variables.
> 
> Yes, that binary is built as part of the NDK build process.

I will make the necessary changes to wifi/main.cc, eliminate the unused
variables and change the prefixes to adhoc_.

> 
> 
>>> * the variables might make more sense as "adhoc_ip" and "adhoc_netmask" since that's really what they are.  The netmask is not used at all for the meshing since olsrd will write an route entry for each node on the mesh it knows about.  The netmask is really there for a new node to establish first contact another mesh node via standard adhoc wifi IP networking.
>>>
>>
>> I think that those are great names! I stumbled around for names until I
>> settled on the mesh_ prefix. We should change them to adhoc_ because, I
>> agree, those are better names.
>>
>> On a semi-related note, I realized that I never quite figured out how
>> you prefer to be addressed? Do you prefer Hans, Hans-Christoph, Your
>> Highness, King?
> 
> Hans is good.

Thanks for the clarification, Hans. I just wanted to make sure that I
wasn't offending you by calling you the wrong name.

Will

> 
> .hc
> 
>>> I also just pushed updates to make commotion-android/external/olsrd now use olsr.org/git/olsrd.git since all of my updates are now included and I have commit access there.  I included your olsrd.conf commit too.
>>>
>>> .hc
>>>
>>> On May 10, 2012, at 3:28 PM, Will Hawkins wrote:
>>>
>>>> Hello all!
>>>>
>>>> I just wanted to send an update. I finished coding up some changes to
>>>> the OLSR mesh tether app that make it even more Commotion-compatible.
>>>>
>>>> 1. DNS: I added some code that will set a DNS server (Google's public
>>>> DNS, by default) while the user is connected to the mesh. There is a
>>>> configuration option (Advanced->Mesh) to change that value. I am going
>>>> to continue working on DNS "stuff" today and tomorrow. My goal is to get
>>>> the Android device to learn any name resolutions passed around in OLSR's
>>>> DNS plug-in.
>>>>
>>>> 2. Configuration: I changed some of the configuration screen
>>>> nomenclature and its semantics. Specifically, I changed the LAN Gateway
>>>> and LAN Netmask under Advanced->IPv4 options to properly reflect their
>>>> use for the mesh. I also added code so that the user can simply enter
>>>> the first quad of an IPv4 address and the client will generate the
>>>> remaining 3 based on the MAC address (this is how Commotion works for
>>>> OpenWRT devices). I changed the name of the entire configuration tab to
>>>> Mesh.
>>>>
>>>> I hope that these are up-to-par and that they are helpful. Please let me
>>>> know if there are any changes that you want made so that they fit code
>>>> style, etc.
>>>>
>>>> Talk to you soon!
>>>> Will
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>
>>>
>>>
>>
> 
> 



More information about the Commotion-dev mailing list