Yun's never show up in Ports menu in 1.6.2

[ronguest]

I installed 1.6.2 and none of my 3 Yuns ever show up in the Ports list. I've waited as long as 5 minutes on each test for one to show up. Clicked on the menu many times as well with no result.

All 3 show up consistently in 1.6.1.

[mschlenker]

We did a Yún workshop on Arduino day and noticed that this issue occured on three PCs running Windows XP and Win 7. Two other PCs running Windows 8.1 did not show the issue. There might be some Avahi issues. Which firmware are you running on the Yún? Which operating system do you use?

[ronguest]

I tested on a MacBook Pro running Yosemite. I don't know how to check firmware versions but when I ssh into my Yuns all 3 say: BusyBox 1.19.4. I've tried to keep up with the Yun firmware updates.

I found the situation weird because I just worked with Federico on a fix in 1.6.1 to make Yun detection more robust (which worked).

[ffissore]

The strange fact is that, while the fix for 1.6.1 was about setting higher timeouts and it worked, 1.6.2 set them even higher and you say it doesn't work any more. Sounds counter intuitive, I need to make some more tests

[mschlenker]

There seem to be a few users that are not very happy with jmdns. I wonder whether there is a more reliable replacement. Anyway, if some testing is needed, I have a variety of OS' to test as well as enough Yúns.

[ronguest]

For the past few releases I've seen the network part of the ports list empty and stay empty about 20% of the time. In 1.6.0 it got worse and Yun's rarely showed up and those with port 80 closed never showed up. In my debugging of that I discovered when the network portion of the ports list was empty there was strange code behavior before the IDE even reached the discovery code. I also observed that some fixes that made sense didn't actually work as expected. It felt like there was a bug somewhere not necessarily in the network code(I'm not saying it is in the IDE code, could easily be a library). I didn't know enough about the IDE code to try to track it down and was happy when I simply had a network discovery solution that worked 80% of the time.

I know people sometimes blame jmdns and I'm sure it isn't perfect. But in my network sniffing & debugging on 1.6.0 I found at times devices just don't respond properly or in a timely fashion. This results in random behavior. I sometimes think a background thread that runs discovery periodically would be better. And it would only remove a device if it wasn't seen for "awhile". E.g. if it runs every 30 seconds it would only remove a previously found device after 2 minutes of non-response.

Federico, I too offer to help. Let me know if I can do something.

[ronguest]

I cloned 1.6.2 and built it. First time I ran it 1 Yun showed up promptly. I then ran the official distribution 3 times and no Yuns showed up at any time. I ran my 1.6.2 and got no Yuns. Ran it again and all 3 showed up. Ran the official build a few times and none showed up. Ran my build again and only 1 one show up, never could get the other 2 to show up.

What a frustrating issue.

[ffissore]

It's probably due to an incorrect way of doing things concurrently. packages list was still null and that caused NetworkDiscovery to silently die
Please give a spin to the latest nighlty build (it includes the fix above): http://arduino.cc/en/Main/Software#nightly

[ronguest]

Hi Federico,

Yes, this is much better :) I did 3 tests. First time it found all 3 Yuns. Second time I could never get it to find the 3rd Yun even though I clicked the Ports menu a half dozen times. Third time it found all 3 Yuns.

Ron

On Apr 13, 2015, at 7:16 AM, Federico Fissore notifications@github.com wrote:

It's probably due to an incorrect way of doing things concurrently. packages list was still null and that caused NetworkDiscovery to silently die
Please give a spin to the latest nighlty build (it includes the fix above): http://arduino.cc/en/Main/Software#nightly http://arduino.cc/en/Main/Software#nightly
—
Reply to this email directly or view it on GitHub #2837 (comment).