OTA network ports list repeats names

[hsgentry]

I use the OTA update with my ESP8266 projects and I have usually have 8 or more nodes. It works very well except that periodically the list of network ports (TOOLS>PORTS) has duplicate names. The IP addresses are correct, but some of the names are duplicated. This is not always the case, sometimes it is all correct. From time to time the list will change and different names are duplicated. Everything else works perfectly and it only started happening when the list of nodes was more than 4 or 5 items long. This is Adruino IDE version 1.8.1.

[facchinm]

Hi @hsgentry ,
is your local network assigning different IP address to the same mac address between flashes or is the mac software-defined?
The board, once disconnected, will disappear from the list as soon as mDNS reports the disconnection (usually in 5 minutes) or when it's not pingable anymore (few seconds). The latter case will only appear when the board doesn't add tcp_check=no in its mDNS record, and AFAIK the ESP8266 core does add this property, so it's normal for the entry not to disappear immediately.

[hsgentry]

All hard Mac addresses. The IP never changes either between flashes or between shutdown/restart of the node. The board disappears if I turn it off as you said. However, I generally don't turn them off. I am periodically making changes and the entire system of devices runs all the time. Everything works fine, I just can't use the network node list to pick a target for update by name. I keep a list of names and ip addresses and select the network node list item that has the correct up, no matter what the IDE thinks the name is. Without any change to the system (no nodes start or stop). The duplicate names in the list changes every time the IDE starts up. The up is always correct and I can download to the node, the name is just duplicated.

…

On Mar 20, 2017 5:02 AM, "Martino Facchin" ***@***.***> wrote: Hi @hsgentry <https://github.com/hsgentry> , is your local network assigning different IP address to the same mac address between flashes or is the mac software-defined? The board, once disconnected, will disappear from the list as soon as mDNS reports the disconnection (usually in 5 minutes) or when it's not pingable anymore (few seconds). The latter case will only appear when the board doesn't add tcp_check=no in its mDNS record, and AFAIK the ESP8266 core does add this property, so it's normal for the entry not to disappear immediately. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQc4UgtMROOUE3_VQ2jrMLcH633_zR-ks5rnkCqgaJpZM4MhvsA> .

[facchinm]

So your problem is about the names not being updated, right?

[hsgentry]

I suppose you could look at it that way. The list has the same name two or three times with different IP addresses. The IP is correct and selecting it I can flash the correct node. I seem to remember that this did not happen when there were only 2 or 3 nodes. As the number of nodes increased the probability that the list will be correct gets lower. With 8 or 10 nodes it seems to NEVER have an entire list that is correct. I just tried starting the IDE 6 or 7 times and there was ONE time that there were no duplicates. Every other time there were between 2 and 5 duplicates. It seems to be almost random. The duplicates are always consecutive in the list: that is, something like this A B C C C X Y Z Z I have never seen duplicates that are not consecutive. I did another series of IDE starts and in EVERY case the correct IP was on the LASTof the duplicates. that is if I had: a 10.0.0.12 b 10.0.0.5 c 10.0.0.67 c 10.0.0.23 c 10.0.0.99 The c with ip 10.0.0.99 is the correct name for that IP. I have never seen the correct name anywhere in the duplicates but last. OK, a lot of information, but I did assembly language, C, C++, and C# for 40 years and I know that you can never be sure when a little information will be a valuable clue!!

…

On Mon, Mar 20, 2017 at 9:37 AM, Martino Facchin ***@***.***> wrote: So your problem is about the names not being updated, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQc4Wlqt9MtsP8oD3ua5S8o5T2e1LCgks5rnoELgaJpZM4MhvsA> .

[facchinm]

Ok, starting from your example:

c 10.0.0.67
c 10.0.0.23
c 10.0.0.99

only c 10.0.0.99 is the valid entry? All other entries are "fake" (or expired)? If it's the case, it totally depends on the aforementioned tcp_check property, and there is nothing we can do about it (unless waiting tor the mDNS record to expire)

[hsgentry]

OK, close, but to take that example again: c 10.0.0.67 c 10.0.0.23 c 10.0.0.99 99 is the correct IP for C, but 67 is the correct IP for a (still active and on line node), and 23 is the correct IP for another, again still talking node. If a node goes away (no longer talking, powered down, etc) it does disappear after a few minutes. The duplicates are always active, talking nodes with valid IP. I can talk to any of them by selecting them from the list. The IDE shows the wrong name, but since the IP is correct it still flashes correctly. The list should be a 10.0.0.67 b 10.0.0.23 c 10.0.0.99

…

On Mon, Mar 20, 2017 at 10:32 AM, Martino Facchin ***@***.***> wrote: Ok, starting from your example: c 10.0.0.67 c 10.0.0.23 c 10.0.0.99 only c 10.0.0.99 is the valid entry? All other entries are "fake" (or expired)? If it's the case, it totally depends on the aforementioned tcp_check property, and there is nothing we can do about it (unless waiting tor the mDNS record to expire) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQc4XNrSCZBQdcmxaX1Hj1FBmNaKW8xks5rno4HgaJpZM4MhvsA> .

[facchinm]

Thanks for the complete explanation 😄 The relevant code is here https://github.com/arduino/Arduino/blob/master/arduino-core/src/cc/arduino/packages/discoverers/NetworkDiscovery.java#L89, all the info displayed are gathered from the underlying jmdns library, so my guess here is that something is getting confused at network level and that fields are not getting populated properly.
Will try to reproduce it in a controlled setup as soon as I get enough ESP8266 boards to play with.
Anyway, just in case, since you discovered this bug with an ESP8266, try filing an issue on their github repo (https://github.com/esp8266/Arduino) so maybe someone who has already encountered this problem can help debugging it
Thanks!

[hsgentry]

Thanks, I will do that. You will probably need 4 or 5 NODEMCU boards and I have always used the option to give the node a name instead of letting it use "ESP8266xxxx" where xxxx is the chip serial number. Hmmmmm. I wonder if there would be any difference if I let it use the default??? Probably not. As far as I am concerned there is no hurry. I have learned to cope. I give each node a password that is related to the node name. That way I can't update the wrong node by accident. If you have any proposed fix I will be glad to give it a try. Thanks again, Sam

…

On Mon, Mar 20, 2017 at 11:44 AM, Martino Facchin ***@***.***> wrote: Thanks for the complete explanation 😄 The relevant code is here https://github.com/arduino/Arduino/blob/master/arduino-core/ src/cc/arduino/packages/discoverers/NetworkDiscovery.java#L89, all the info displayed are gathered from the underlying jmdns library, so my guess here is that something is getting confused at network level and that fields are not getting populated properly. Will try to reproduce it in a controlled setup as soon as I get enough ESP8266 boards to play with. Anyway, just in case, since you discovered this bug with an ESP8266, try filing an issue on their github repo (https://github.com/esp8266/Arduino) so maybe someone who has already encountered this problem can help debugging it Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQc4Se35w7mCnZj1U35TMmeXz5uDsoAks5rnp7YgaJpZM4MhvsA> .

[hsgentry]

in reference to: [arduino/Arduino] OTA network ports list repeats names (#6094) *Well, even after 40 years I don't understand computers. We had a power failure that was long enough to shutdown even the UPS supported hardware and everything rebooted. Now the problem is gone!! I have been watching it for several days and there just is no problem. It must have been an issue with the DNS or DHCP server or a router or the like. *

…

On Mon, Mar 20, 2017 at 8:45 AM, Sam Gentry ***@***.***> wrote: All hard Mac addresses. The IP never changes either between flashes or between shutdown/restart of the node. The board disappears if I turn it off as you said. However, I generally don't turn them off. I am periodically making changes and the entire system of devices runs all the time. Everything works fine, I just can't use the network node list to pick a target for update by name. I keep a list of names and ip addresses and select the network node list item that has the correct up, no matter what the IDE thinks the name is. Without any change to the system (no nodes start or stop). The duplicate names in the list changes every time the IDE starts up. The up is always correct and I can download to the node, the name is just duplicated. On Mar 20, 2017 5:02 AM, "Martino Facchin" ***@***.***> wrote: > Hi @hsgentry <https://github.com/hsgentry> , > is your local network assigning different IP address to the same mac > address between flashes or is the mac software-defined? > The board, once disconnected, will disappear from the list as soon as > mDNS reports the disconnection (usually in 5 minutes) or when it's not > pingable anymore (few seconds). The latter case will only appear when the > board doesn't add tcp_check=no in its mDNS record, and AFAIK the ESP8266 > core does add this property, so it's normal for the entry not to disappear > immediately. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#6094 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGQc4UgtMROOUE3_VQ2jrMLcH633_zR-ks5rnkCqgaJpZM4MhvsA> > . >