Closed ffissore closed 10 years ago
Comment by jantje Saturday Dec 07, 2013 at 15:04 GMT
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
Comment by tigoe Saturday Dec 07, 2013 at 15:42 GMT
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.
Comment by jantje Saturday Dec 07, 2013 at 16:09 GMT
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.
Comment by jantje Tuesday Dec 10, 2013 at 00:03 GMT
is this something the arduino core team is willing to look at?
Comment by tigoe Tuesday Dec 10, 2013 at 00:34 GMT
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.
Comment by jantje Tuesday Dec 10, 2013 at 19:55 GMT
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
Comment by fibasile Tuesday Dec 10, 2013 at 21:30 GMT
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
Comment by noblepepper Tuesday Dec 10, 2013 at 21:45 GMT
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.
Comment by jantje Tuesday Dec 10, 2013 at 22:46 GMT
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
Comment by fibasile Sunday Dec 15, 2013 at 22:38 GMT
hi, i'm still working on the config part, I'll do my best to have it done asap
Comment by fibasile Monday Dec 16, 2013 at 16:02 GMT
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.
Comment by jantje Monday Dec 16, 2013 at 16:48 GMT
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..
Comment by fibasile Monday Dec 16, 2013 at 16:54 GMT
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
Comment by jantje Monday Dec 16, 2013 at 18:05 GMT
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.
Comment by fibasile Monday Dec 16, 2013 at 18:31 GMT
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.
Comment by jantje Monday Dec 16, 2013 at 18:49 GMT
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.
Comment by fibasile Monday Dec 16, 2013 at 19:00 GMT
btw, you can use this quick script to start with https://github.com/mdomi/hosts
Comment by jantje Monday Dec 16, 2013 at 19:27 GMT
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
Comment by jantje Monday Dec 16, 2013 at 19:52 GMT
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
Comment by jantje Monday Dec 16, 2013 at 20:37 GMT
this is the script I came up with to start the whole thing
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.
Comment by thomas-c Monday Dec 16, 2013 at 23:38 GMT
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
The subject has been discussed again on the forum: http://forum.arduino.cc/index.php?topic=260388 As @thomas-c suggested, I would install mdnsresponder package or (maybe better) howl-mdnsresponder http://downloads.arduino.cc/openwrtyun/1/packages/howl-mdnsresponder_1.0.0-4_ar71xx.ipk
I'll give them a shot asap /cc @jantje @noblepepper @fibasile @tigoe as this issue was imported from the old repo
And they don't work. I'm trying with packages nss and nss-mdns found here https://github.com/tobiaswaldvogel/openwrt-addpack
Nope, does not compile. Closing the issue if in the coming weeks there won't be updates
Do we have solution to his? Or it is still impossible to resolve the name from within OpenWrt?
It's been working okay for me. I can't reproduce the problem, sorry.
sent on the go. please excuse brevity and mistaken auto corrections On Sep 21, 2015 5:57 PM, "Drasko DRASKOVIC" notifications@github.com wrote:
Do we have solution to his? Or it is still impossible to resolve the name from within OpenWrt?
— Reply to this email directly or view it on GitHub https://github.com/arduino/openwrt-yun/issues/7#issuecomment-142121927.
@tigoe what do you use? nss-mdns
is not present in Chaos Calmer because it depends on glibc.
Caveat: been a couple months since I checked. But I didn't install anything special. I was just using whatever mdns lib is in the current yun dist and it showed up on my networks fine.
sent on the go. please excuse brevity and mistaken auto corrections On Sep 21, 2015 6:17 PM, "Drasko DRASKOVIC" notifications@github.com wrote:
@tigoe https://github.com/tigoe what do you use? nss-mdns is not present in Chaos Calmer because it depends on glibc.
— Reply to this email directly or view it on GitHub https://github.com/arduino/openwrt-yun/issues/7#issuecomment-142125628.
The script I provided works fine.
@jantje is it integrated in the source tree? What's the location?
The code is here available on this page. a couple of messages above
Issue by jantje Saturday Dec 07, 2013 at 15:03 GMT Originally opened as https://github.com/arduino/linino/issues/16
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