[Commotion-dev] DNS Update

Hans-Christoph Steiner hans at guardianproject.info
Fri Jun 22 21:50:18 UTC 2012


Sorry, I was out for my wedding and am still catching up.  I will definitely check this out first thing next week.

.hc

On Jun 13, 2012, at 1:30 PM, Will Hawkins wrote:

> Hey Hans,
> 
> Just wondering if you had a chance to consider these patches?
> 
> On 05/16/2012 01:01 PM, Will Hawkins wrote:
>> I uploaded a set of patches to redmine that should implement this.
>> Please take a look at your convenience and provide feedback. I am eager
>> to hear what you think.
>> 
>> To get the new feature, follow the instructions in the README (basically
>> update android.env and run ./build_external.sh).
>> 
>> As an overview, here's how the new dns setup works:
>> 
>> On connection to the mesh,
>> 1. the user's DNS server preference is taken from the preferences and
>> stashed in app_bin/resolv.conf
>> 2. The system-wide dns server is set to 127.0.0.1
>> 3. adsuck (the name of the dns server binary) is launched. Its pid is
>> stored in the app_bin/adsuck.pid file.
>> 4. olsrd is started with a properly configured nameservice plug-in.
>> At this point, adsuck is now ready to do .mesh -> address translations.
>> 
>> When olsrd receives an updated DNS entry,
>> 1. The mapping is automatically reflected in
>> app_bin/chroot/hosts.android.small.
>> 2. The adsuck process (whose pid is found in app_bin/adsuck.pid) is
>> signalled with HUP to indicate that there were changes to its data source.
>> 3. adsuck rereads app_bin/chroot/hosts.android.small.
>> 
>> On disconnection from the mesh,
>> 1. The application resets the system-wide dns server to what it was
>> before connecting.
>> 
>> Please let me know if this makes sense. I am eager to get feedback on
>> the approach and how it works. It's pretty cool to be able to go to
>> http://commotion-xxxx.mesh from the Android browser.
>> 
>> Will
>> 
>> 
>> On 05/15/2012 03:30 PM, Will Hawkins wrote:
>>> You can now find discussion of this item on Redmine in the
>>> commotion-android project under Feature #300.
>>> 
>>> https://code.commotionwireless.net/issues/300
>>> 
>>> Will
>>> 
>>> On 05/15/2012 01:25 PM, Will Hawkins wrote:
>>>> Thanks for this Hans.
>>>> 
>>>> This setup is meant now only for Android, but it could be useful for
>>>> other platforms that do not readily support /etc/hosts-formatted files.
>>>> In all honesty I never considered a Java DNS implementation that could
>>>> simply run in a separate thread. That is something that I will
>>>> definitely look into.
>>>> 
>>>> As for the files themselves, these do go into the app-local data
>>>> directories. The installation definitely does not pollute the OS file
>>>> system beyond that. I'm sorry if there was confusion in my previous
>>>> email regarding that point.
>>>> 
>>>> Will
>>>> 
>>>> On 05/15/2012 12:09 PM, Hans-Christoph Steiner wrote:
>>>>> 
>>>>> Sounds good.  Is this setup meant to be only for Android or other platforms too?  I ask because it'll probably be easier to manage a pure Java DNS server as an Android Service than adding another C binary.
>>>>> 
>>>>> As for writing out a non-standard file like /etc/hosts-formatted, if you are writing a custom file, then it should go into the app's file hierarchy.  It is important to avoid touching the filesystem as much as possible.  This file could go into /data/data/net.szym.barnacle/app_bin or we could create ...../app_etc or something like that.
>>>>> 
>>>>> .hc
>>>>> 
>>>>> On May 14, 2012, at 4:22 PM, Will Hawkins wrote:
>>>>> 
>>>>>> Hello all!
>>>>>> 
>>>>>> I just wanted to give everyone an update on what's going on here: I am
>>>>>> working on adding capability to the client to handle DNS entries
>>>>>> distributed in the mesh (via olsr nameservice plugin). Because Android's
>>>>>> /etc/hosts file is on the readonly file system, simply telling olsrd to
>>>>>> write out an /etc/hosts file (like it would normally do on a *nix host)
>>>>>> does not work.
>>>>>> 
>>>>>> So, I cross-compiled a small (300k) DNS server that the app invokes when
>>>>>> the user connects to the mesh. This server answers queries by first
>>>>>> looking for an answer in an /etc/hosts-formatted file. If there are no
>>>>>> matches, the DNS server forwards the request.
>>>>>> 
>>>>>> In my testing it works fairly well. I am still integrating it into the
>>>>>> build but I wanted to give everyone an update.
>>>>>> 
>>>>>> Talk to you all soon!
>>>>>> Will
>>>>>> _______________________________________________
>>>>>> Commotion-dev mailing list
>>>>>> Commotion-dev at lists.chambana.net
>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>> 
>>> 
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>> 
>> 
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>> 
> _______________________________________________
> 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