Router Resolving mDNS with nonsensical addressses

[Arhowk]

Hello! So I've been unpacking our teams KoP and setting up a freshly updated board and playing with the router. In some tests, I've noticed something peculiar about the router and how it resolves mDNS. The first time you request an address from it, it will return an IPv6 address that doesn't exist. The second time and subsequent times within an instanenous time frame will return an ipv4 address that is valid. For a visualization, see the command log

C:\Users\illid_000>ping roborio-1684-frc.local

Pinging roborio-1684-frc.local [fe80::280:2fff:fe17:6109%11] with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for fe80::280:2fff:fe17:6109%11:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\illid_000>ping roborio-1684-frc.local

Pinging roborio-1684-frc.local [10.16.84.59] with 32 bytes of data:
Reply from 10.16.84.59: bytes=32 time=1ms TTL=63
Reply from 10.16.84.59: bytes=32 time=1ms TTL=63
Reply from 10.16.84.59: bytes=32 time<1ms TTL=63
Reply from 10.16.84.59: bytes=32 time=1ms TTL=63

Ping statistics for 10.16.84.59:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\Users\illid_000>

I don't believe this to be computer side because I've tested with two different computers, NI MDNS on both and Bonjour on one and recieved the same results on every test.

Is anyone else experiencing this issue?

[rzoeller]

While I can't attest to this specifically, we had an overall very... weird experience using the new router for RI3D. So this would not surprise me, and validates the issues we had.

[Arhowk]

Originally Posted by rzoeller

While I can't attest to this specifically, we had an overall very... weird experience using the new router for RI3D. So this would not surprise me, and validates the issues we had.

Okay, I've also had other rather quirky issues with the new router. For one, whenever I tried to deploy the team number to the router, the router would turn off whenever it was pinged. That problem was fixed after I switched ethernet ports. Not sure what happened there.

I started investigating this issue after python deploy times went from 2s to ~30s with a huge hang on "finding robot". At this point I'd just go back to my 2015 mindset of "You get a static IP! You get a static IP! Everyone gets a static IP!!!"

[rzoeller]

We experienced issues where a computer would disconnect, and refuse to re-establish robot communication upon reconnection unless the wireless card was taken down entirely (e.g. not just turning off wireless, the adapter had to be disabled and re-enabled or rebooted). This issue persisted across both tested computers (different wireless cards), although both were running Windows 10, so it is possible that the issue does not lie entirely with the router.

[Arhowk]

Originally Posted by rzoeller

We experienced issues where a computer would disconnect, and refuse to re-establish robot communication upon reconnection unless the wireless card was taken down entirely (e.g. not just turning off wireless, the adapter had to be disabled and re-enabled or rebooted). This issue persisted across both tested computers (different wireless cards), although both were running Windows 10, so it is possible that the issue does not lie entirely with the router.

Hm, that is strange, this laptop is running windows 10 and I haven't encountered any issues like that.

[rzoeller]

Originally Posted by Arhowk

Hm, that is strange, this laptop is running windows 10 and I haven't encountered any issues like that.

I want to note that we had to manually flash the firmware, as RI3D teams don't get an official KOP. It's possible that the firmware posted is slightly different than what shipped on the KOP router.

[Arhowk]

It's a possibility... we're testing right now but I'll reflash the router when we get back to building and see if that resolves anything

[rzoeller]

Originally Posted by Arhowk

It's a possibility... we're testing right now but I'll reflash the router when we get back to building and see if that resolves anything

The utility installed with the FRC update kit only works with router's that come preinstalled with the KOP system I believe. We followed the directions that came on the box for our router, see here.

[Scott L.]

IPv6 fe80::/64 are link local addresses.
In IPv4 169.254.0.0/16 are the link local addresses

[rich2202]

Originally Posted by Arhowk

I started investigating this issue after python deploy times went from 2s to ~30s with a huge hang on "finding robot". At this point I'd just go back to my 2015 mindset of "You get a static IP! You get a static IP! Everyone gets a static IP!!!"

I remember in a prior year the Subnet mask causing delays. For competition, you need 255.0.0.0, which means the deploy program will search all possible team numbers. However, if you limit it to 255.255.255.0, then it will only search your team number for the robo rio.

[Arhowk]

Reflashing the firmware on the radio did resolve the problems we were having. The IPv6 address that it pings to the first time around is actually valid and points to the RIO.

[virtuald]

Originally Posted by Arhowk

Reflashing the firmware on the radio did resolve the problems we were having. The IPv6 address that it pings to the first time around is actually valid and points to the RIO.

Does that mean you're no longer having deploy issues?

[Arhowk]

Originally Posted by virtuald

Does that mean you're no longer having deploy issues?

Yep. Deploy times are back down to 4-5seconds