This afternoon, while we were testing robot stuff, I noticed that our Windows driverstation was able to resolve roborio-1418.local, and our OSX machines were not able to do so. This struck me as strange, as I hadn’t had problems with resolving the address in the past.
However, tonight while looking around for other things, I found this message in the logfile ‘/var/log/messages’:
Jan 10 21:43:38 roboRIO-1418 nimDNSResponder: Local Hostname roboRIO-1418.local already in use; will try roboRIO-1450.local instead
After seeing this, I decided to look at my local mDNS settings, and lo and behold I found my roborio as ‘roboRIO-1450.local’ instead! I suspect there’s a bug in the NI mdns responder… or at least some unanticipated behavior. Any thoughts?
I haven’t seen that error message before. I was wondering if you are using the USB connection. I commonly used mDNS from my mac, but of course it only works on ethernet or wifi, as I don’t have a mac driver for enet over USB.
We’re seeing the same issue on both of our RoboRIO. For now, we’ve worked around the problem by using static addresses - it would be good to have this working though.
We did some investigation on this on the robot’s network, and the two mdns processes are definitely conflicting with each other. I can’t imagine why both are enabled – I suspect an oversight?
Anyways, I disabled the avahi-daemon from starting, and the problem went away. I would recommend that NI/FIRST remove one of the mdns daemons from future images.
Interestingly, I don’t have this problem when the robot is connected to my network at home, only on the network connected to an FRC configured router.
I tried the link-local thing, and I’m not sure if it made a difference. I don’t think it did.
When we disable avahi-daemon and enable NI’s mDNSResponder, then the Driver Station software can no longer connect to the robot, but OSX can resolve the robot’s .local address.
When we disable NI’s mDNSResponder and enable avahi-daemon, then the Driver Station software can connect to the robot, but OSX cannot resolve the robot’s .local address.
When we enable both, then the Driver Station software works, but OSX cannot resolve the robot’s local address. Additionally, we get the errors in the /var/log/messages.
It is actually not an oversight as it turns out. I was as surprised as you at first. I dug into the reason and found out that the system configuration people have settled on avahi as the mDNS software for the platform. Unfortunately for the vision group, avahi does not have an API to return all of the IP address records returned by the queried device. The way Axis implemented mDNS on their cameras is incompatible with this since it returns a link-local address (If link-local could work consistently when you have more than one network interface it wouldn’t matter.) even when the camera has a DHCP or static configured address, and in an unreliable order. The maintainer of avahi, Lennart Poettering, has made it clear that he doesn’t want to support returning more than one IP address. This limitation does not exist with mdns-responder, so the vision team opted to run that as well! :rolleyes:
I’m not sure there is a way to stop running both and still support Axis cameras, but hopefully there is a way to make avahi responses make it back to the mac. Do you have pcap files showing the working vs. non-working traffic?