EZ-Bv4 Firmware Updater Issue

First, thanks - good detail in your report. A few quick questions before steps so I can narrow this down:

• How are you connecting when you run the Firmware Updater: WiFi (IP/AP) or USB/COM?
• When you power the EZB v4, do you hear the startup sound? Does the camera stream in ARC (if you have a camera attached)?
• Can ARC otherwise control the EZB (move servos, read sensors) or does it connect only briefly then drop immediately?
• Do you have a USB/COM connection available (Device Manager shows a COM port) to try an alternate update path?

Troubleshooting steps to try now

1. Verify power and reduce load

• Use a stable power source (7.4V is common for 2S LiPo / safe for most EZRobot servos).
• Remove servo and heavy-load peripherals while updating. Brownouts during updates can break a flash process and cause disconnects.

2. Determine whether the I/O processor is responding

• If the EZB does NOT play the startup sound or ARC connection stalls during the firmware ID stage, the bottom I/O board may be unresponsive (manual symptom). If the communication board is alive but the I/O board is dead, the updater will connect briefly then drop - exactly what you’re seeing.
• Quick check: does the camera stream work? Camera can still work when the I/O board is damaged because the top comm board handles video. If camera works but startup sound and I/O features do not, that points to I/O board failure.

3. Try a direct AP connection and web page check

• Power the EZB, connect your PC to the EZB WiFi (AP mode), then open https://192.168.1.1 in a browser.
• If the web page loads, the EZB communications board is alive. The web page may show battery/firmware info. If you cannot reach the page, note any error.

4. Try updating via USB/COM (alternate path)

• If you’ve been using WiFi, try connecting the EZB via USB/serial to your PC and update using the COM port in ARC.
• In Windows Device Manager, confirm the USB serial driver (COM port) appears (CH340/CP210x, etc.).
• In the Connection control -> CONFIG -> COM/USB Connection tab, ensure the correct baud (default) and try enabling DTR/RTS if required. Then run the Firmware Updater on that COM connection.

5. Run the Connection Diagnostic skill and capture logs

• In ARC: Project -> Add robot skill -> General -> Connection Diagnostic (add it).
• Start the skill, click Ping EZB and let it run. Use the Copy Log to Clipboard button and paste the log here. The diagnostic output will show where in the handshake it fails (useful to confirm whether the firmware ID is returned or the log stops earlier).
• Also copy/paste the ARC status window logs (bottom of ARC) after an update attempt.

6. Try multiple networks was good - next try a direct PC EZB singlenetwork (no router) connection

• Connect your PC directly to the EZB AP or to the same single WiFi network (no VPNs or multiple adapters). Disable other network adapters temporarily (or disable internet adapter) so ARC communicates only with the EZB.

7. Confirm ARC & Updater versions and the exact updater you run

• You said you tried both previous and newest ARC - good. Please tell me the exact ARC versions you tested and the firmware updater dialog messages (copy the text if possible).

Why this often happens (short explanation)

• If the connection establishes but then immediately disconnects, the top comm CPU may accept a TCP session but the I/O processor never returns its firmware ID or responds to commands. That behavior is described in the EZB v4 manual and usually indicates the bottom I/O board is not responding (electrical damage or I/O failure). But we must confirm with logs before assuming hardware failure.

What I need from you

• The Connection Diagnostic log (paste here).
• Answer the questions at top (WiFi or USB, startup sound, camera, ARC control working).
• If possible, attach the exact text/error from the ARC status window when updater disconnects.

Links and references

• EZB v4 firmware / hardware overview: https://synthiam.com/Support/Hardware/EZ-B-v4
• EZB Connection skill info: https://synthiam.com/Support/Skills/Communication/EZB-Connection?id=16041
• Connection Diagnostic skill info (how to capture verbose connection logs): https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164
• Connection troubleshooting: https://synthiam.com/Support/troubleshooting/Connection-Troubleshooting

Next steps after you post logs

• I’ll read the diagnostic output and tell you whether it’s a likely I/O board fault, a WiFi/handshake timing issue we can fix, or a driver/COM issue. If it’s a hardware I/O problem, I’ll explain the symptoms clearly and what to test next (e.g., more verification steps you can do at home).

If you want, start by running the Connection Diagnostic and pasting its log here (or paste the ARC status window text). I’ll analyze it and give the specific next action.

I am connecting via WiFi AP mode. I am using a stable battery power source. Yes, both EZ-Bv4 controllers I have used connect to ARC and the cameras are operational. Start up sounds normal. The webserver is accessible on both controllers.

Here is the diagnostic text for the firmware updater:

Quote:

4/1/2026 5:46:42 PM - Disconnected 4/1/2026 5:46:42 PM - EZB Not Responding:Unable to connect to 192.168.1.1:23. This PC appears to be connected to a network with the IP address that was specified. However, the connection could not be established with the EZB.

I know there has been some changes to the way EZ-B controllers connect to ARC, has this disrupted the original functionality?

Thanks - that’s very helpful detail. Based on what you’ve reported (AP mode, webserver and camera OK, startup sound OK) the EZ-B top communication board is alive. The diagnostic message ("Unable to connect to 192.168.1.1:23") says the firmware updater cannot open the EZ-B TCP port (23) - so this looks like a network/TCP (or local firewall) issue, not an I/O board hardware failure.

Here’s a focused troubleshooting plan and exactly what I need next so I can narrow it down.

1. Quick theory (why this is happening)

• ARC/Updater is trying to connect to the EZ-B on TCP port 23 but the connection is refused or times out.
• Because the web UI and camera stream work, the top (comm) board is fine; port 23 not responding can mean:
  • EZ-B is not accepting raw TCP on port 23 (server disabled / in client mode).
  • A PC firewall or another app is blocking outbound connections to port 23.
  • A network routing/adapter conflict on the PC (multiple adapters, VPN, etc.).
  • Something else on the EZ-B changed its TCP listener (rare) or the firmware process that handles that port is not running.

2. Tests I need you to run (copy/paste results) Run these on the PC that is connected to the EZ-B AP. Paste results here.

• Ping the EZ-B (simple connectivity)

  • Windows CMD: ping 192.168.1.1

• Test TCP connectivity to port 23

  • PowerShell: Test-NetConnection -ComputerName 192.168.1.1 -Port 23
  • (Alternative) if you have telnet client enabled: telnet 192.168.1.1 23
  • Paste full PowerShell output or telnet behavior.

• Check if any local process is interfering (optional)

  • PowerShell: netstat -an | findstr ":23"

• Copy the exact text from the ARC Status window immediately after an updater attempt (you said diagnostic shows it; paste it here).

3. Firewall & network adapter checks

• Temporarily disable Windows Firewall (or any third-party firewall) and retry the PowerShell Test-NetConnection and the firmware updater. If that fixes it, re-enable firewall and create an outbound rule for port 23 to the EZ-B IP.
• If your PC has more than one network adapter (WiFi + Ethernet + VPN), disable all adapters except the one connected to the EZ-B AP and retry. (Multiple adapters can confuse which adapter attempts the connection.)

4. Check the EZ-B web config for connection mode

• Open the EZ-B web page at https://192.168.1.1 and look for a network/connection or services section that mentions "Client/Server", "TCP shell", or similar.
  • If the EZ-B is configured in "client" mode (it tries to connect to ARC instead of listening), it won’t be listening on port 23. Switch to AP/server mode or ensure it is set to accept incoming TCP on port 23 temporarily while running the updater.
• If there’s a toggle for any "TCP shell server" or "telnet/raw TCP" service, ensure it is enabled while you update firmware.

5. USB/COM troubleshooting (since you’re also having COM issues)

• On Windows, open Device Manager and confirm whether a COM port appears when you connect USB. Tell me the COM number and the USB driver name (CH340, CP210x, Microsoft USB Serial, etc.).
• If no COM appears:
  • Try a different USB cable and port (use a direct PC USB port, not a hub).
  • If Device Manager shows an unknown device, reinstall the correct drivers for CH340 / CP210x depending on your board.
• If a COM appears but ARC’s Connection control won’t connect:
  • Open the Connection skill kebab menu (three-lines on the skill window) CONFIG COM/USB Connection.
  • Ensure correct baud (default for EZ-B firmware flash is automatic; try 115200 if you must set one).
  • Try enabling DTR and RTS checkboxes (some USB<>UART bridges require these).
  • Save and use Connect0 (or the index you use) and paste the ARC status log here after the attempt.

6. Firmware Updater details

• Which ARC version(s) did you test? Paste the exact version string from Help About in ARC for the versions you tried.
• When you run the Firmware Updater, copy the full text log (you already pasted one line). The more lines the better.

7. Temporary workarounds / suggestions

• If Test-NetConnection shows port 23 closed but webserver/camera work: try switching the EZ-B into AP client/server settings (if available) on the web UI so it listens for raw TCP, then re-try updater.
• If firewall or VPN is the problem, disabling them usually proves that.
• If USB COM is not available, confirm the COM device driver and try on another PC if possible (this helps determine if PC-side drivers are the issue).

8. Has ARC changed behavior recently?

• ARC is updated periodically, but the firmware update path (connecting to EZ-B on raw TCP) has not been intentionally removed. Most connection failures are caused by local firewall, client/server mode misconfiguration, or USB driver changes on the PC rather than ARC removing functionality. Based on your symptoms (web UI + camera OK but port 23 not reachable) this is likely a connectivity/config issue rather than an ARC regression.

9. Next steps after you run the tests

• Paste the output of:
  • ping 192.168.1.1
  • Test-NetConnection -ComputerName 192.168.1.1 -Port 23
  • netstat -an | findstr ":23"
  • ARC status window log lines immediately after the updater fails
  • Device Manager COM device name/number (if present)
• I’ll analyze those and give the exact next action (e.g., enable a specific EZ-B web setting, create a firewall rule, or use an alternate COM workflow).

If you’d like, I can also provide step-by-step screenshots text for opening the Connection skill kebab menu and changing DTR/RTS, or the exact PowerShell commands to run. Which would you prefer next?

I've never used Powershell, here's goes nothing:

I used your prompt: 

Quote:

Test-NetConnection -ComputerName 192.168.1.1 -Port 23

Quote:

Test-NetConnection - 192.168.1.1:23 Attempting TCP connect

Waiting for response

and then a little while later the following text was displayed in PowerShell:

Quote:

ComputerName : 192.168.1.1

RemoteAddress : 192.168.1.1

RemotePort : 23

InterfaceAlias : Wi-Fi 3

SourceAddress : 192.168.1.2

TcpTestSucceeded : True

Nice work - that Test-NetConnection result is useful. TcpTestSucceeded: True and the EZ-B connect/disconnect sound means ARC (or the Updater) is successfully opening TCP to port 23 and the EZ-B responds - so the low-level network path is ok. That narrows this down to one of:

• Something on the PC (firewall, antivirus, another app) is stealing/closing the connection,
• ARC / Updater process is making the connection but immediately failing the handshake, or
• A local service or driver issue (COM/UART, or another ARC instance) interfering.

Next tests (please run these and paste the results)

1. See which process is using the TCP socket while the updater runs (Windows CMD as Administrator)

• Start the Firmware Updater so it makes its connect attempt (so you hear the connect then disconnect).
• Immediately open an elevated command prompt (Run as Administrator) and run:

netstat -ano | findstr ":23"

• If you see a line that shows 192.168.1.1:23 and a PID at the end, get the process name:

tasklist /FI "PID eq <that PID>"

(Replace <that PID> with the PID number shown by netstat.) Paste both outputs here. This will tell whether ARC/updater is the active process or some other program grabbed/closed the connection.

2. Collect detailed ARC status & Connection Diagnostic logs

• In ARC, open the Connection Diagnostic skill (Project Add robot skill General Connection Diagnostic).
• Start the Firmware Updater and let it fail once (so you hear connect/disconnect).
• In the Connection Diagnostic window click Copy Log to Clipboard and paste the log here.
• Also copy the ARC Status window text at the bottom of the ARC UI (press the COPY button there) and paste it here.

3. Temporarily disable firewall/AV and retest

• Completely disable Windows Defender Firewall and any third-party AV/firewall momentarily and retry the Firmware Updater.
• If the updater succeeds with firewall/AV off, we know we need a firewall rule for outbound TCP to 192.168.1.1:23 (I’ll give exact rule steps when you confirm).

4. Try a raw telnet session and watch behavior

• On the same PC (Command Prompt) run:

telnet 192.168.1.1 23

(If telnet client is not installed, you can enable it by "Turn Windows features on/off".)

• Note whether telnet connects and then drops immediately, or whether the connection remains open. Paste the exact response.

USB/COM troubleshooting (you said COM ports 9/10/11 appear) You said you tried 3 USB-TTL adapters and swapped TX/RX, RTS/CTS. A few checks and reminders:

• Use the correct UART connection on the EZ-B v4:
  • If you are connecting to the expansion UART pins, use UART0 on the expansion connector (the EZ-B manual shows UART0 on the expansion connector). Other UARTs map to D5/D6 and D18/D19 as listed in the manual.
• TTL voltage: the EZ-B uses 3.3V TTL. Verify your USB-TTL adapters are configured for 3.3V logic (not 5V). 5V could damage or cause odd behavior.
• Common ground is required - connect GND of USB-TTL to EZ-B ground.
• Do NOT permanently power Vcc from the USB-TTL unless you know voltages match. Usually leave adapter Vcc disconnected if EZ-B is already powered.
• Try a terminal like PuTTY to open the COM port at 115200 (or auto-detect) and see if any bytes appear when you power-cycle the EZ-B. Example PuTTY settings: Serial, COM9, 115200, 8,N,1. If you see data during boot or when ARC tries to connect, paste it.

Also try this: with the EZ-B powered and your USB-TTL connected, open Device Manager note the COM port in ARC Connection skill kebab menu CONFIG COM/USB settings:

• Set the COM to that port, try 115200, and try toggling DTR/RTS checkboxes (save and Connect).
• After a connect attempt, copy the ARC status window and paste.

Information I need from you

• ARC version (Help About paste the version exactly).
• The Connection Diagnostic log you paste (from step 2).
• netstat / tasklist outputs (step 1).
• Result of telnet (step 4).
• Exactly which pins/wires you used for the USB-TTL (which EZ-B connector and which wires connected to TX/RX/GND; mention whether you connected VCC).

Why I’m asking all this

• Test-NetConnection showing True tells us the EZ-B accepts TCP, but the immediate disconnect suggests either the updater starts a handshake that the EZ-B rejects (we’ll see that in the diagnostic logs), or another program / firewall is interfering and closing the socket (the netstat + tasklist check will reveal that). The USB/COM side may be independent - if the USB path cannot be established because of wiring/voltage or driver issues, we can isolate that separately.

If you prefer, run the netstat command while the Updater is running and paste results first - that often tells me immediately whether ARC is actually the process that connected and dropped, or whether something else is involved.

When you paste the logs and outputs I’ll examine them and give the exact next action (firewall rule, AR C setting to change, or precise wiring/driver fixes for USB).

I could only get your commands to work when I connected to ARC

First output:

Quote:

TCP 192.168.1.2:56701 192.168.1.1:23 ESTABLISHED 26268

Quote:

Image Name PID Session Name Session# Mem Usage ========================= ======== ================ =========== ============ ARC.exe 26268 Console 1 349,896 K

Quote:

4/1/2026 10:24:42 PM - Attempting connection on 192.168.1.1:23 4/1/2026 10:24:42 PM - Sending: 85 4/1/2026 10:24:43 PM - NetworkStream.Read received 1 of 1 bytes. 4/1/2026 10:24:43 PM - Expected: 1 bytes Received (1 bytes): 42 4/1/2026 10:24:43 PM - Connected to 192.168.1.1:23 (tx timeout: 2000, rx timeout: 2000, tx buffer: 20000 rx buffer: 20000) 4/1/2026 10:24:43 PM - Reports EZB v4 OS With Comm 2 4/1/2026 10:24:43 PM - Firmware 'EZ-B v4.x/2 Native Firmware' (0x02) on 'EZ-Robot EZ-B v4.x/2' supports the following capabilities:

• ADC with 12 bit Resolution
• Can stream Audio v4 codec
• Reports battery voltage
• Reports CPU temperature
• Read/Write Digital I/O Ports
• Hardware UART TX/RX with DMA buffer and adjustable baud rate
• I2C Master
• LIPO battery protection & shutdown
• PWM Duty on digital ports
• PWM servos on digital ports
• PWM servos on digital ports can release their position
• Servo speed for PWM servos on digital ports
• Has NVRam configuration and can be restored to default settings
• Transmit Uart TX on all digital ports
• Adjustable I2C clock speed
• Configurable UART TX digital port baud timing
• Ultrasonic Ping distance sensor support
• 12 Byte Unique Identifier
• Can stream video v4 codec
• Native UART Connectivity from ARC
• Native WiFi Connectivity from ARC
• Broadcasts to ARC's PnP network scanner

4/1/2026 10:24:43 PM - Sending: 2 4/1/2026 10:24:43 PM - NetworkStream.Read received 11 of 12 bytes. 4/1/2026 10:24:43 PM - NetworkStream.Read received 1 of 12 bytes. 4/1/2026 10:24:43 PM - Expected: 12 bytes Received (12 bytes): 79 50 0 0 120 255 59 57 58 37 38 38 4/1/2026 10:24:43 PM - EZ-B v4.x/2 Native Firmware ID: 79-50-0-0-120-255-59-57-58-37-38-38 4/1/2026 10:24:43 PM - Setting battery monitor voltage: 7.0 4/1/2026 10:24:43 PM - Sending: 4 1 20 7 4/1/2026 10:24:43 PM - Setting battery protection: True 4/1/2026 10:24:43 PM - Sending: 4 0 1 4/1/2026 10:24:43 PM - Sending: 4 18 0 10 15 4/1/2026 10:24:43 PM - Sending: 4 18 1 133 7 4/1/2026 10:24:43 PM - Sending: 4 18 2 191 3 4/1/2026 10:24:43 PM - Sending: 4 18 3 221 1 4/1/2026 10:24:43 PM - Sending: 4 18 4 60 1 4/1/2026 10:24:43 PM - Sending: 4 18 5 157 0 4/1/2026 10:24:43 PM - Setting i2c rate: 100000 4/1/2026 10:24:43 PM - Sending: 4 17 160 134 1 0 4/1/2026 10:24:43 PM - Sending: 4 2 4/1/2026 10:24:43 PM - NetworkStream.Read received 2 of 2 bytes. 4/1/2026 10:24:43 PM - Expected: 2 bytes Received (2 bytes): 239 7 4/1/2026 10:24:43 PM - EZ-B voltage is 7.84v 4/1/2026 10:24:43 PM - Sending: 4 3 4/1/2026 10:24:43 PM - NetworkStream.Read received 2 of 2 bytes. 4/1/2026 10:24:43 PM - Expected: 2 bytes Received (2 bytes): 172 3 4/1/2026 10:24:43 PM - EZ-B temperature is 24.76c Connecion Status: True 4/1/2026 10:24:43 PM - Connected 4/1/2026 10:24:43 PM - Sending: 172 90 173 90 175 90 176 90 178 90 179 90 181 90 182 90 184 90 185 90 187 90 188 90

By the way the "Copy Log to clipboard" button does not seem to work for me with the latest version of ARC and Windows 11. I did not seem to copy to the clipboard because when I went to paste the previous copied text was pasted. I had to manually select, copy, and paste the log.

I also tried turning off Windows defender Firewall and then connecting in the firmware updater again, the same result happened. The connect sound was made immediately followed by the disconnect sound and message.

Trying to connect via Telnet, here's the message:

Quote:

Error #1002: You do not appear to be a valid ARC instance. Closing Connection!

Connection to host lost.

Thanks - this is excellent troubleshooting detail. The logs show the important facts:

• ARC successfully connects to the EZ-B v4 and completes the handshake (Connection Diagnostic shows Firmware ID, voltage, temp, etc.).
• Test-NetConnection and netstat confirmed ARC (ARC.exe PID 26268) has an ESTABLISHED TCP session to 192.168.1.1:23.
• When you try a raw telnet session you get: "Error #1002: You do not appear to be a valid ARC instance. Closing Connection!" - that is expected because a raw telnet client does not perform the ARC protocol handshake the EZ-B expects.
• The firmware updater attempt connects (you hear connect) then disconnects immediately - the most likely cause is a connection conflict: the Connection skill (ARC) already has the socket open, or another process is holding the TCP session, so the Updater cannot establish the required protocol/handshake cleanly.

What to try (stepbystep)

1. Ensure ARC is not already connected to the EZ-B

• In ARC, open your Connection control and press Disconnect (or use the command to disconnect the connection index you use). To disconnect all connections from a script or the Script Console:

controlCommand("Connection","DisconnectAll");

• Confirm netstat shows no ESTABLISHED connection to port 23:
  • Open an elevated Command Prompt and run: netstat -ano | findstr ":23"
  • Expect no lines showing 192.168.1.1:23.

2. Stop any other ARC windows/controls that may auto-connect

• Close Camera windows / Connection Diagnostic windows / any other skills that might auto-connect to the EZ-B. Some skills will auto-reconnect the socket in the background and block the Updater.

3. Run the Firmware Updater only after all other ARC connections are closed

• With ARC completely disconnected from the EZ-B (Connection -> Disconnect), then start the Firmware Updater and perform the update. If the updater is built into ARC, ensure you are launching the updater from the same ARC instance but only after the Connection control is disconnected.

4. If the Updater still connects then immediately disconnects

• Immediately after it fails, run:
  • netstat -ano | findstr ":23"
  • If you see an ESTABLISHED or TIME_WAIT entry, note the PID and run: tasklist /FI "PID eq <PID>"
  • Paste the PID and tasklist result back here - this tells us which process is making the connection and whether it’s ARC or another program.

5. Don’t use raw Telnet to test the Updater

• Telnet will not behave like ARC (EZ-Builder protocol) and will produce the Error #1002 message. That’s normal for telnet and not a sign of firmware corruption.

6. If you want to use USB/Serial update instead

• Make sure you are wired to the EZB UART pins correctly:
  • USBTTL TX -> EZ-B RX, USBTTL RX -> EZ-B TX, and connect GND->GND.
  • Use 3.3V logic level (do NOT use 5V on signal pins).
  • Do NOT power the EZ-B from the USB-TTL Vcc unless you absolutely know your voltages match.
• In ARC Connection skill, select the COM port shown in Device Manager and try to connect (enable DTR/RTS if needed in the COM config). If Connection via COM succeeds, run the Firmware Updater over that COM connection.
• If COM never connects: try a different PC to isolate whether the problem is the PC drivers or the board.

7. Workaround if ARC’s Connection skill keeps re-opening the socket

• Sometimes the Connection skill will auto-reconnect (or another installed skill will). Close ARC entirely, then reopen ARC and launch the Firmware Updater immediately before opening the Connection skill or any other controls. Or temporarily remove the Connection skill from the project so nothing can auto-connect.

Why this will likely fix it

• The EZB allows one valid EZBuilder style client to connect and requires the client to perform an expected handshake. If a connection is already held by ARC (Connection skill) the Updater cannot take over cleanly and the EZB will close the connection. Ensuring the Connection skill is disconnected and no other clients are active will free the socket for the Updater to do its handshake and flash.

One more detail and a couple questions

• You said the Connection Diagnostic "did not update when trying to connect to the EZB in the firmware updater." That fits the "another process already has the socket" theory. Please confirm you disconnected the Connection control before running the Updater. If not, try the steps above.
• Please confirm the ARC version (Help -> About -> paste the exact version string).
• If the updater still immediately disconnects after you ensure no other connections exist, paste the output of:
  • netstat -ano | findstr ":23"
  • tasklist /FI "PID eq <PID>" (if you see a PID)
  • the firmware updater diagnostic lines (copy/paste the full text shown in ARC after the updater attempt)
  • the Connection Diagnostic log captured while the updater runs (select+copy manually if the Copy Log button is failing)

If you want, do this now:

• Disconnect Connection in ARC.
• Run the firmware updater.
• If it fails, immediately run: netstat -ano | findstr ":23" and paste the results here (and tasklist for any PID shown). I will analyze that and give the exact follow-up (firewall/process kill, or another configuration change).

Useful references

• EZB v4 hardware/firmware: https://synthiam.com/Support/Hardware/EZ-B-v4
• Connection Diagnostic: https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164
• Connection control docs: https://synthiam.com/Support/Skills/Communication/EZB-Connection?id=16041

Want me to provide the exact keyboard/menu steps (with screenshots style text) to disconnect the Connection skill and launch the updater safely? I can list them in order so you can follow them stepbystep.

I completely rebooted my computer so that no other program was connected to the EZ-Bv4, I connected to the EZ-Bv4 WiFi SSID, loaded the firmware updater and tried to connect again. The same result was found again, connect then immediate disconnect.

I really think there's been a change to the firmware updater source code during the last few ARC updates. It has never been this difficult to connect to the firmware updater.

Telnet on port 8080 works to communicate with the EZ-Bv4, do you think that the firmware updater is supposed to use port 8080 and somehow the code has been changed to use another port?