Yun: Bonjour service (ip resolution) does not work on yun.

[jantje]

When you have 2 yuns on the same network called yun1 and yun2 it is not possible to ping yun2 from yun1 using ping yun2.local yun2.local is not resolved to a ip adress. Pinging with the ip adress works fine. This issue is discussed here http://forum.arduino.cc/index.php?topic=202577.msg1492883#msg1492883 it seems like the service nss-mdns is missing.

I think this is a important feature when you have multiple yun's on the same network who need to work together. I for instance need it to have my robot(s) communicating with a base station.

The alternative's I know are 1) using the work around parsing avahi-resolve -n yunX 2) Using fixed IP adresses I find both workarounds very clumsy. Therefore I think this is important for the yun that this issue is fixed.

Best regards Jantje

[jantje]

Some background info I gathered on this issue As far as I understood the nss-mdns is missing because in openwrt Dnsmasq is assumed to be used. http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq I quote "The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file."

From a network perspective however I can not rely on a DHCP server running on a yun. Running multiple DHCP servers is not an option for me as I do not have enough control over the DHCP server provided by my ISP.

Best regards Jantje

[tigoe]

Interesting. We’ve been running multiple yuns on our network at NYU without this problem (albeit with different problems, related to the network itself. We weren’t using Yun1.local and yun2.local, though. We’re using things like tomsyun.local, joesyun.local, etc. or using the IP address directly.

t.

On Dec 7, 2013, at 10:04 AM, jantje notifications@github.com wrote:

Some background info I gathered on this issue As far as I understood the nss-mdns is missing because in openwrt Dnsmasq is assumed to be used. http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq I quote "The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file."

From a network perspective however I can not rely on a DHCP server running on a yun. Running multiple DHCP servers is not an option for me as I do not have enough control over the DHCP server provided by my ISP.

Best regards Jantje

— Reply to this email directly or view it on GitHub.

[jantje]

Wether it is working or not is dependent on the dns, dhcp or other services you are running on your network. If you dhcp server supports bonjour than you are ok. Dnsmasq is not going to work out of the box with the yun as yun does not use a name to register with the dhcp service.

[jantje]

is this something the arduino core team is willing to look at?

[tigoe]

I’ll defer to Cristian and Federico Fissore here. I guess my answer would be: if it doesn’t lessen stability and doesn’t add significant memory to the main image, I’d be happy to see someone submit a pull request with a patch.

t.

On Dec 9, 2013, at 7:03 PM, jantje notifications@github.com wrote:

is this something the arduino core team is willing to look at?

— Reply to this email directly or view it on GitHub.

[jantje]

I am not advocating to get this in the main image. Whether or not it should be in the main image is indeed a design decision for Cristian or Federico Fissore.

My point is that the design decision was taken to start from a "network device oriented linux" for linino. Also the design decision was taken to use dhcp and bonjour as default way of working. As it turns out these design decisions make that yun's can not reach each other via name but need some dirty workaround to get to the ip address. So that they can communicate via ip address. As an architect I'd say that (given the above): this is something the core team needs to fix.

IMHO the solution is to provide the nss-mdns package. Users having multiple yuns who need to talk to each other can install this package. The source code is available http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-0.10.tar.gz I'm willing to test packages. However the actions to setup a lininio development environment + making lininio packages to make a pull request seems a bridge to far right now for me.

Jantje

[fibasile]

Hi, I think the issue is important, especially during workshops and similar events. I don't have mulitple yuns but got some experience on the build environment. I can try to have this built if you are available for testing it

[noblepepper]

The patch here http://patchwork.openwrt.org/patch/759/ will compile and produce a package that installs without errors once you add a nss.h file (I used the one in /usr/include on Ubuntu) but it does not enable the *.local resolution on the yun. This could be caused by either inappropriate values in nss.h or my inability to configure correctly once installed.

Good Luck! Please keep up informed if you are successful.

-----Original Message----- From: Fiore Basile notifications@github.com Reply-to: arduino/linino <reply +i-23906321-2cd15467e1dfabb3f80a61db73e1b5cd522dea75-987531@reply.github.com> To: arduino/linino linino@noreply.github.com Subject: Re: [linino] Yun: Bonjour service (ip resolution) does not work on yun. (#16) Date: Tue, 10 Dec 2013 13:30:43 -0800

Hi, I think the issue is important, especially during workshops and similar events. I don't have mulitple yuns but got some experience on the build environment. I can try to have this built if you are available for testing it

— Reply to this email directly or view it on GitHub.

[jantje]

yes I'm willing to test. To set the right level of expectation : I do need clear instructions on how to get the test material on the yun. Once it is there I can buzz around it. Jantje

[jantje]

Is there a expected time for a test set?

[fibasile]

hi, i'm still working on the config part, I'll do my best to have it done asap

[jantje]

txs great :-)

[fibasile]

I'm sorry, but it looks like nss-mdns by itself cannot work on the Yun.

This is because the uclibc, which is used by linino instead of glibc doesn't have support for nss, so resultion requests don't get routed to mdns via nss-mdns which is a just a plugin for nss.

See https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt

I'm now trying to compile nss itself first, but it's not an easy task as the mozilla distribution for nss is quite complicated piece of software.

I found there is some patch to make it compatible with uclibc https://bugzilla.mozilla.org/show_bug.cgi?id=670142

If you want to try by yourself I can provide you a compiled ipk for nss-mdns.

[jantje]

first of all: Thank you very much for seriously looking at this issue. It really is appreciated.

This is because the uclibc, which is used by linino instead of glibc doesn't have support for nss, so resultion requests don't get routed to mdns via nss-mdns which is a just a plugin for nss.

Sounds like bad news. Even thought I am very well aware I don't know what I'm talking about; I would like to propose considering this way forward: As nss is difficult (and I guess it is as it seems like some flexible plug and play manager thing); would it not be easier to directly call the mdns core feature? ( core feature = provide ip for name?) I mean somewhere in the uclibc code a translation module "name to ip" must exist. This module is different from Glibc that Glibc extends it with nss as a manager for services to do additional lookups. If we could extend the uclibc code to also look for bonjour services it could be simpler and smaller than supporting nss. Thinking really wild (and hoping ) I guess uclibc has some code to read the /etc/hosts file. It is probably easy to extend the code to not only read /etc/hosts but also /tmp/hosts.bonjour. The only thing remaining then is a tasks that queries avahi and creates the /tmp/hosts.bonjour file. I can do that with a script (Probably not the best way but should work).

Best regards Jantje

note1: Putting the file in tmp makes the file is autocleaned at startup which I consider good practise. note2: I'm using /tmp/hosts.bonjour but that could be a different name. Feel free to change. I mean that the file could support sections or tags so multiple tools could write in the same file; as such bonjour should not be part of the name..

[fibasile]

well, if you create a script that writes down the info into /tmp/hosts.bonjour you could dynamically update the /etc/hosts file directly and not have to change a single line into core libraries

[jantje]

well, if you create a script that writes down the info into /tmp/hosts.bonjour you could dynamically update the /etc/hosts file directly and not have to change a single line into core libraries

Good thinking (I hadn't thought of it). And it definitely can be used as a temporary work around. However I see some problems with modifying /etc/hosts on a long term basis first of all the file is in flash memory so you are killing the flash memory. Secondly /etc/hosts doesn't get cleaned after restart so it can contain wrong info. One could say that it does get fixed because your service will clean when it starts but who says the service will start?

For the flash: As to wikipedia http://en.wikipedia.org/wiki/Flash_memory#Memory_wear flash has a typical 100,000 P/E cycles. Assuming the script causes 1 P/E cycle a minute the wear will be there in 100000/24/60=70 days. (I agree that the script can be optimized to reduce the P/E's but still ...)

A better work around may be to link /etc/hosts to /tmp/hosts and have the script to update /tmp/hosts. If this work around works it definitely takes off the pressure for me. I do think a "good solution" should be implemented.

I'm starting on the workaround. And I'll keep you posted.

[fibasile]

For the workaround I would suggest to symlink to /mnt/sda1/ rather than /tmp so you won't boot with an empty hosts file. It is recommended anyway to use sdcard when you plan to change files often on the yun. You could also alter the init.d scripts to wipe any edits from the hosts file when shutting down or rebooting.

[jantje]

IMHO /tmp is memory so the best place to be for this. But I may be wrong. I think you are proposing smart things.... but I'll try to get it to work first.

[fibasile]

btw, you can use this quick script to start with https://github.com/mdomi/hosts

[jantje]

this works fine to get the hosts

avahi-browse -t -a |grep "[" | awk -F" " '{print $5,$4}'|tr -d '[]' > /tmp/hosts

When I create a symlink I'll move the old file to hosts.org. I'll look at int.d to replace the symlink of /etc/hosts with /etc/hosts.org Then I'll make a script to move /etc/hosts to /etc/hosts.org , create the link and call the above command every minute

You could also alter the init.d scripts to wipe any edits from the hosts file when shutting down or rebooting.

Which script do I need to edit for boot and shutting down time?

note: there is a \ in front of the [ in grep but it is not shown

[jantje]

the previous command gave the mac adresses and not the IP's This is better

avahi-browse -t -r -a -p |grep "^=;wlan0"|awk -F";" '{print($8,$7)}'|sort -u

[jantje]

this is the script I came up with to start the whole thing

!/bin/ash

HOSTS=/etc/hosts HOSTSORG=/etc/hosts.org HOSTSDYNAMIC=/tmp/hosts if [ -f ${HOSTSORG} ]; then echo "the avahi workaround had not been undone properly" if [ -h ${HOSTS} ]; then echo "Nothing has been removed." echo "continuing" else if [ -f ${HOSTS} ]; then echo "both " ${HOSTS} " and " ${HOSTSORG} "exist. " echo "quiting" exit else echo ${HOSTS} " was removed but" ${HOSTSORG} " not put back." echo "relinking " ${HOSTS} " to " ${HOSTSDYNAMIC} echo continuing ln -s ${HOSTSDYNAMIC} ${HOSTS} fi fi else mv ${HOSTS} ${HOSTSORG} ln -s ${HOSTSDYNAMIC} ${HOSTS} fi

while [ 1 ] do cat ${HOSTSORG} > ${HOSTSDYNAMIC} avahi-browse -t -r -a -p |grep "^=;wlan0"|awk -F";" '{print($8,$7)}'|sort -u >> ${HOSTSDYNAMIC} sleep 60 done

it works on my yun. If you can help me with integrating the stop in the yun sutdown that would be great.

[thomas-c]

If Avahi has issues, perhaps mDNSResponder might work, which I think is from Apple: http://download.linino.org/dogstick/all-in-one/latest/packages/mdnsresponder_214.3.2-4_ar71xx.ipk

I think the above contains both the responder and client components, which are here separately: http://download.linino.org/dogstick/all-in-one/latest/packages/mdnsd_214.3.2-4_ar71xx.ipk http://download.linino.org/dogstick/all-in-one/latest/packages/mdns-utils_214.3.2-4_ar71xx.ipk

BSD man pages, but likely still applicable: http://www.manpagez.com/man/8/mDNSResponder/ http://www.manpagez.com/man/1/dns-sd/

https://developer.apple.com/bonjour/

EDIT: nevermind, this readme from a recent source explains that mdnsd also requires nss_mdns: http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-522.1.11/mDNSPosix/nss_ReadMe.txt