04-19-2012 08:48 AM
My LV Real-time 11.0.1 machine keeps giving me the message that there is another host using my ethernet address, but neither myself nor the IT guys can understand why it is giving us such message as we can find no other entity with that address on our network.
"ETS TCP/IP: device ether0: another host is using our Ethernet Address"
Direction on diagnosing this problem would be appreciated.
04-20-2012 04:47 PM
Typically, when we see this error, it does mean exactly what it says. Have you tried unplugging or turning off your device and pinging the ip address? If the IP address is still pingable, that would tell us that something else on the network has the IP address.
When exactly are you seeing this error? Does it occur every time you boot up? It might be helpful if you posted a screen shot of the error.
Also, what hardware do you have? Is sounded like maybe a real-time desktop?
Do you have it set up to have a static IP address? If so, could you try allowing it to acquire an IP address via DHCP (unless that isn't possible on your network). Does the same thing happen if you let acquire its own ip address?
04-23-2012 02:09 PM
The console on the Desktop real time system is reporting the conflict as follows:
Monitoring network traffic suggests that the Real Time System is reponding badly to the answer given by our core switch of a mDSN query from the RT system:
The real time system is issuing this query periodically and it corresponds to the "other host" message showing up in the console log.
PS: Re: Your other questions. This error occurs regardless of if I use DHCP or Static Assignments, and nothing else on the network responds to a ping of that address when the Desktop RT is powered off. My suspician is that the RT system is having problems with the response of our core switch to it's mDNS query. I am a bit surprised that it is even doing this as I am using RT to try and have more control over when/how the systems goes out and does anything I do not explicitly tell it to go do.
04-24-2012 08:59 AM
Have you tried connecting to the system via a crossover cable? This would help ascertain whether or not it's a problem with the hardware or its interaction with the network.
04-24-2012 09:53 AM
The system is electrically connected properly. I am able to download software, execute software, etc. The console screen dump I posted in my last response was generated by my office workstation connecting to the Desktop Realtime workstationstation using NI Network Browser, so it is not a wiring problem.
As I mentioned, I think the desktop real time system is mis-interpreting the core switch's response to it's mDNS query. For some reason that we do not understand, it seems to be interpreting the response to mean that some other machine is using that address, which is not the case.
04-24-2012 10:06 AM
ETS will throw that error ("someone else is using my IP address") if it sees a packet (from anywhere) with its IP address or MAC address in the source field. Is your core switch responding as if it's the target? Is that correct?
04-25-2012 12:48 PM
When we monitor the interface, the only thing we see concurrent with the error message being thrown is a pair of mDNS packets, that appear to be eminating from the ETS system. We don't see any other traffic with that IP or hardware address as either a source or destination when the error is generated on the ETS console. Note that I blocked out part of the source IP address, but they are both the same in the two packets shown below. These were the packets on the net when the ETS kicked out one of its periodic error messages.
I don't understand why the system would generate two of these packets within 2ms of each other, but then again, the complexities of modern networks never cease to amaze me and this isn't my "day job".
Thanks for your help on this.
04-26-2012 05:00 PM
Removing the switch from the loop might be informative. I didn't mean to imply that your device wasn't wired up correctly - it would just be good to verify whether or not the error would occur in a different network setup. My suggestion for an alternative setup would be to try connecting up to the desktop with a crossover cable.