[Commotion-dev] Submitted DNS and configuration changes

[Hans-Christoph Steiner]

On May 11, 2012, at 11:38 AM, Will Hawkins wrote:

> On 05/11/2012 11:36 AM, Hans-Christoph Steiner wrote:
>> 
>> On May 11, 2012, at 11:05 AM, Will Hawkins wrote:
>> 
>>> 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.
>> 
>> 
>> Have you seen the "No Network" warnings when OLSRMeshTether is active?  For example, when going to the olsrd httpinfo webpage, the browser will pop up an error message saying "you have no network!  Settings/OK".  Cliking OK makes it go away, then it works.  
>> 
> 
> Yes, I have seen that! I will try to dig around and see how we can
> convince the OS that it does have a network connection. Like you said,
> it does actually work despite the warning message. Unfortunately it's
> not the best user interface. :-)


Yeah, this is a tricky thing.  The app starts out by telling Android to turn off the wifi, so Android is being honest from its perspective.  I've seen people use their own custom wpa_supplicant which reports ad-hoc networks as infrastructure networks, then Android shows them in the interface.  That might work, but we might end up banging our heads against differences in the vendor supplied wpa_supplicants.  Very much an open question...

Oh yeah, another thing, before you start submitting lots of patches, I should rename the java package.  I'll try to do that after this round of patches.

.hc