Unable to auto-detect Ether1616 <resolved>

[clough42]

I had the grounds connected when everything was in the box. I didn't bother once I took it all out. I'm happy to reconnect and test again, but I'm also certain it won't make any difference.

And...in the spirit of gathering way too much information, I hooked up a couple of packet sniffers, and I do see the ARP request for the broadcast address going out on the Ethernet interface, followed immediately for an ARP for the Acorn address, and only the Acorn responds:

Sniffing from another computer connected to the switch, I do see the ARP for the broadcast address appearing on the wire, but nothing else (possibly because the switch isn't routing responses to my switch port):

I see the same behavior with Windows Defender on or off.

[clough42]

I get Ping responses from 10.168.41.2 and 10.168.41.3.

The Acorn seems to work fine. I configured the ESTOP input, and the UI responds when I hit the mushroom switch. I haven't configured anything else.

[clough42]

Incidentally, the IP address range for my WiFi network is 10.98.76.0/24, in case that matters. I was seeing the same results with the WiFi interface disabled, though.

Is it worth installing CNC12 on another computer to test? Will I be able to do that with my license?

[tblough]

James (great channel by the way) the license is tied to the Acorn, not the computer, so by all means, try another computer if you have one.

[clough42]

Thanks!

I just installed CNC12 on my laptop, and it found the Eth1616 instantly. So I think that means it has to be an issue with the computer. Not sure what that would be.

[clough42]

Okay, the plot thickens (again). When I tested with the laptop, which worked, I was using an external USB-C to USB hub and Ethernet dongle. So I plugged that dongle into the other PC I had been using and switched to that Ethernet device, and...it works!

Both the external (USB) and internal (PCIe) network adapters are Realtek GbE Family devices. Any idea why the USB one would work, but the internal PCIe one would not?

[clough42]

Okay, I think I have this solved. The solution was super subtle. I had to turn off the hardware ARP offload in the driver Advanced settings tab of the Realtek PCIe network device:

With that change, it now works.

What follows is half observation, half speculation (and half rationalization) but I think there's a bug in the handling of multicast ARP responses in the Realtek hardware. Or at least there's a difference that affects the CNC12/Eth1616 discovery. In the network traces, I could see the ARP requests for the broadcast address going out on the wire, but I didn't see any responses coming back. I did, however, see responses for single-address ARP requests. Looking through the settings on the driver, it's configured by default to offload ARP processing to the Realtek chip. I don't think this is a big performance advantage; I think it's primarily so the machine can respond to ARP requests while in sleep. Turning it off handles the ARP requests in software instead of in the chip, and this appears to make the discovery work correctly.

In any case, it works. The moment I double-click the CNC12 icon in Windows, the LED display on the Eth1616 starts scrolling, and it shows up. I've rebooted the machine and power-cycled the Acorn and Eth1616 hardware multiple times and so far it seems stable.

[centroidsupport]

Great news. FWIW I never meant to imply WIFI had anything to do with it. I was simply reporting how my machine was configured

[eng199]

Good troubleshooting work!
In your packet sniffer, you should see a UDP broadcast when the software tries to detect ETH1616. Now that you fixed it, you should see that UDP broadcast, not just the ARP broadcasts.

[clough42]

Good troubleshooting work!
In your packet sniffer, you should see a UDP broadcast when the software tries to detect ETH1616. Now that you fixed it, you should see that UDP broadcast, not just the ARP broadcasts.

And in fact, this is exactly what I see. The ETH1616_RESPOND message goes out to 10.168.41.255 and it immediately receives back ETH1616_AT 10.168.41.3. No drama.

Interestingly, I no longer see the ARP request for the broadcast address. It's blindly transmitting the UDP packet to physical address ff:ff:ff:ff:ff:ff. So that appears to be the bug: with ARP offload enabled, it's erroneously sending an ARP request for 10.168.41.255 (and not getting a response) instead of recognizing that it's the local segment broadcast address. Subtle.