Related Products: 64ARM1, 68G5, 75ARM1, 75G5, 75INT2, NIU1A


How does Ethernet work on NAI devices?

When your application (or ESP2) talks to an NAI board over Ethernet, it isn’t reaching the modules directly — it connects to a small listener process running on the board. The listener accepts the connection, performs the register reads and writes on your behalf, and returns the results. No listener, no connection — even when the network itself is perfectly healthy.

All our Generation 5 boards implement four listeners, across two ports:

ListenerProtocolPort
TCP 1TCP52801
TCP 2TCP52802
UDP 1UDP52801
UDP 2UDP52802

Each port can support multiple connections, and all four ports can operate simultaneously without threading issues. However, there is no arbitration between them: a connection on one port can overwrite data written from another port — or from another connection on the same port. Individual ports can be turned off through the EEPROM, but there is currently no mechanism to restrict the number of simultaneous connections.

Why can I ping the board but not open a connection?

This is the most common Ethernet symptom, and it’s expected behavior — ping and an NAI API connection exercise two different things:

  • ping uses ICMP, which the board’s operating-system network stack answers automatically as soon as the board has an IP address on your subnet. A successful ping confirms the network path is good — cabling, IP, subnet, and routing.
  • An NAI API connection uses TCP/UDP on ports 52801 / 52802, which succeed only if the listener process is running and that port is enabled. The listener is a separate application sitting on top of the network stack.

So a board can answer ping the instant it finishes booting while still refusing API connections — because the listener either hasn’t started, isn’t enabled on the port your host is targeting, or has been turned off in EEPROM. “Can ping, can’t connect” almost always means the network is fine, but the listener isn’t up.

Note

The listener only matters when you connect to the board from a host — a dev-PC application or ESP2 — over Ethernet. An application running onboard the SBC itself reaches the modules directly and does not need the listener.

Does the listener start automatically?

That depends on the operating system running on the board:

  • ARM / PetaLinux (and other Gen5 ARM / VxWorks / Deos targets): the listeners start automatically at boot, controlled by the EEPROM OpMode Listeners at Startup field. If host connections are failing, confirm that field is non-zero and that the four OpMode TCP/UDP Port values match the ports your host is using — both are shown by naiMBEEPROMUtil formatteddisplay.
  • Onboard Linux x86 (68INT5 / 68INT6 / 68INT6H on Ubuntu, 75INT2 on CentOS): the listener does not start automatically. The SSK image ships a listener application that you must start manually from the board’s terminal each boot. Until you do, a remote host can ping the board but cannot reach its modules.