Support for RAK ethernet module by rgregg · Pull Request #1983 · meshcore-dev/MeshCore

rgregg · 2026-03-09T21:57:05Z

This pull request adds Ethernet support to the companion_radio, simple_repeater, and simple_room_server examples for nRF52-based devices, enabling TCP CLI access and mesh command handling over Ethernet. It also updates the build workflow to include new Ethernet-enabled targets. The main changes are grouped below by theme.

Everything is compile-time gated by the ETH_ENABLE flag which is only enabled for a new environment profile for RAK firmware + Ethernet support.

Ethernet support for examples

Added Ethernet initialization, hardware setup, and DHCP management to examples/simple_repeater/main.cpp and examples/simple_room_server/main.cpp, including FreeRTOS task for background handling and unique MAC address generation. [1] [2]
Implemented TCP server and client handling for CLI access via Ethernet, including command parsing and reply formatting for both repeater and room server examples. [1] [2] [3] [4]
Added command handling logic for Ethernet CLI, including support for the "eth" command to report connection status and IP address. [1] [2] [3] [4]

Integration and initialization

Updated setup() and loop() functions in all examples to start Ethernet tasks, maintain connections, and handle mesh commands from both serial and Ethernet interfaces. [1] [2] [3] [4] [5] [6] [7] [8] [9]
Modified examples/companion_radio/main.cpp to support conditional inclusion of Ethernet interface and initialization, including debug output and error handling. [1] [2] [3] [4]

Build workflow updates

Added new Ethernet-enabled build targets for nRF52 devices in .github/workflows/pr-build-check.yml to ensure CI coverage for the new features.

These changes collectively enable robust Ethernet-based CLI and mesh communication for nRF52 devices, improving flexibility and connectivity options.

Copilot

Pull request overview

Adds compile-time-gated Ethernet (RAK13800/W5100S) support to nRF52 example apps to enable TCP-based CLI access and mesh command handling, and extends CI to build the new Ethernet-enabled targets.

Changes:

Added Ethernet initialization/DHCP + TCP CLI handling to simple_repeater and simple_room_server (behind ETH_ENABLED).
Added an nRF52 SerialEthernetInterface and wired it into companion_radio when ETH_ENABLED is set.
Introduced new RAK4631 PlatformIO environments + CI matrix entries for Ethernet-enabled builds.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
`variants/rak4631/platformio.ini`	Adds new RAK4631 Ethernet-enabled PlatformIO envs and dependencies.
`variants/rak4631/RAK4631Board.cpp`	Attempts to hook Ethernet init into board bring-up (macro-gated).
`src/helpers/sensors/EnvironmentSensorManager.cpp`	Avoids treating the Ethernet power IO as a GPS-detect pin when Ethernet is enabled on RAK boards.
`src/helpers/nrf52/SerialEthernetInterface.h`	Introduces Ethernet-backed serial interface abstraction for nRF52.
`src/helpers/nrf52/SerialEthernetInterface.cpp`	Implements W5100S init, TCP server/client framing, and DHCP maintenance.
`examples/simple_room_server/main.cpp`	Adds ETH task + TCP CLI parsing/command handling for room server example.
`examples/simple_repeater/main.cpp`	Adds ETH task + TCP CLI parsing/command handling for repeater example.
`examples/companion_radio/main.cpp`	Adds conditional Ethernet serial interface + ETH maintenance in main loop.
`.github/workflows/pr-build-check.yml`	Adds CI builds for the new Ethernet-enabled RAK4631 targets.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…mpanion Add W5100S Ethernet adapter support for RAK4631-based firmware, enabling TCP CLI access on port 23 as an alternative to BLE/Serial connections. - New SerialEthernetInterface for nRF52 with DHCP, reconnection handling, and shared WB_IO2 power pin management with GPS module - Ethernet build targets for repeater, room server, and companion firmware - Prevent GPS from toggling WB_IO2 when Ethernet module is active - CI build check for all three ETH firmware targets Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

- Add #pragma once to SerialEthernetInterface.h - Rename TCP_PORT to ETH_TCP_PORT with #ifndef guard - Fix typos: "initalizing" → "initializing" - Fix #elif without condition → #else for STM32 block - Replace infinite loop on ETH init failure with halt() - Remove heartbeat Serial.print(".") output - Remove dead beginETH() call (ETH_ENABLED, not RAK_ETH_ENABLE) - Comment out MESH_DEBUG and ETH_DEBUG_LOGGING build flags Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

rgregg · 2026-03-11T04:02:29Z

Updated to address all the issues in the Copilot feedback.

liamcottle

Howdy! Thanks for the PR. I've added some comments :)

rgregg · 2026-03-11T05:44:00Z

Thanks @liamcottle for the review and the feedback - I've updated the PR to reflect your feedback, I appreciate your time!

liamcottle

Awesome, thanks for the adjustments. I've gone through again and have some extra comments. Once these are sorted, would be good if you can test it's all working before I ask Scott to do a code review.

liamcottle · 2026-03-11T06:34:50Z

+
+  // Check for new TCP client connections
+  static void ethernet_check_client() {
+    if (ethernet_client && ethernet_client.connected()) return;


I think this check would prevent new clients from being able to connect until the existing client disconnects. The WiFi firmware allows new connections to kick off old connections. We should allow the same here.

Fixed - removed the early return guard so server.available() is always called. New connections now replace existing ones.

JDat · 2026-03-11T11:08:11Z

Can this be made to work with W5500-EVB-PICO (Wiznet5500 + RPi Pi Pico RP2040) board because RAK is no the only toy with Ethernet.

neopiccolorat · 2026-03-11T11:42:40Z

This PR comes at the right time!
I have this RAK13800 and I'm currently using with Meshtastic, but I wanted to switch this node to Meshcore and still being able to connect to it by its ip.

rgregg · 2026-03-11T15:18:42Z

Can this be made to work with W5500-EVB-PICO (Wiznet5500 + RPi Pi Pico RP2040) board because RAK is no the only toy with Ethernet.

Should be possible to extend. I don't have that hardware to test/validate with though.

- Rename eth command to eth.status for consistency with other commands - Rename generateDeviceMac to generateEthernetMac for clarity - Refactor ethernet_handle_command to return false by default - Allow new TCP clients to replace existing connections (repeater, room server, SerialEthernetInterface) - Boot companion radio without Ethernet on init failure (LoRa-only recovery mode) - Remove > prompt from ethernet CLI for consistency with serial interface - Fix variable redeclaration compile error in SerialEthernetInterface when ETHERNET_STATIC_IP is defined - Fix TCP socket leak when duplicate client detection fires - Remove dead recv_queue and adv_restart_time members from SerialEthernetInterface - Fix port numbers in docs (port 23 for repeater/room server CLI, port 5000 for companion radio) - Clarify eth.status command is only available in repeater and room server firmware Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

JDat · 2026-03-12T16:02:48Z

Can this be made to work with W5500-EVB-PICO (Wiznet5500 + RPi Pi Pico RP2040) board because RAK is no the only toy with Ethernet.

Should be possible to extend. I don't have that hardware to test/validate with though.

I have this board and I am OK to solder/wire LoRA module with board, and do some tests.

…ate CLI code The Ethernet retry loop in repeater and room server checked hardwareStatus() and linkStatus() before calling Ethernet.begin(), which always returned EthernetNoHardware since hardware detection only happens during begin(). Extract shared Ethernet CLI code into EthernetCLI.h to prevent future divergence. Also fix time_t type mismatch in companion radio Ethernet init. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

rgregg · 2026-03-13T18:01:54Z

All three Ethernet-enabled firmwares have been tested on RAK4631 hardware with the RAK13800 W5100S Ethernet module and are working as expected:

RAK_4631_repeater_ethernet — DHCP + CLI over telnet (port 23) ✅
RAK_4631_room_server_ethernet — DHCP + CLI over telnet (port 23) ✅
RAK_4631_companion_radio_ethernet — DHCP + companion protocol (port 5000) ✅

Resolve conflicts: keep both Ethernet CLI and SenseCAP power-off button code in repeater, keep both Ethernet docs and power management CLI docs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

rgregg · 2026-03-13T18:08:46Z

@liamcottle - let me know if there is anything else, otherwise I think this is ready to merge.

JDat · 2026-03-14T10:04:04Z

For what reason Ethernet header sit inside nRF52 helper directory? What if Ethernet need to be added to ESP32 and RP2040 microcontrollers. What a crazy platform dependent b**t! If you want Ethernet support, make it platform independent instead or only board laying on your table!

rgregg · 2026-03-14T15:53:26Z

For what reason Ethernet header sit inside nRF52 helper directory? What if Ethernet need to be added to ESP32 and RP2040 microcontrollers. What a crazy platform dependent b**t! If you want Ethernet support, make it platform independent instead or only board laying on your table!

This follows the existing pattern of SerialBLEInterface which lives in the esp32 and nrf52 folders. Firmware development is often very hardware specific - if it turns out we can reuse the same code, it'll be easy enough to refactor it accordingly when someone with the hardware can verify it works. There's no need to be rude about it.

JDat · 2026-03-14T20:37:02Z

For what reason Ethernet header sit inside nRF52 helper directory? What if Ethernet need to be added to ESP32 and RP2040 microcontrollers. What a crazy platform dependent b**t! If you want Ethernet support, make it platform independent instead or only board laying on your table!

This follows the existing pattern of SerialBLEInterface which lives in the esp32 and nrf52 folders. Firmware development is often very hardware specific - if it turns out we can reuse the same code, it'll be easy enough to refactor it accordingly when someone with the hardware can verify it works. There's no need to be rude about it.

Why not to refactor things correctly as soon as they are developed? Is this future of vibe coding or what?

rgregg · 2026-04-26T20:28:56Z

Thanks for the review @oltaco! I've updated the PR based on your feedback.

cwichura · 2026-05-06T13:04:24Z

@rgregg Would you consider adding support for redirecting MESH_PACKET_LOGGING to the Ethernet session (at least for non-companions)? This would allow mctomqtt (with the TCP PR waiting on it applied) to act as an observer to a device with PoE Ethernet as its hardwired connectivity. Currently, MESH_PACKET_LOGGING writes to Serial., which goes to the USB serial console output. Thanks.

mcode6726 · 2026-05-06T20:29:23Z

+size_t SerialEthernetInterface::checkRecvFrame(uint8_t dest[]) {
+  // check if new client connected; new connections replace existing ones
+  auto newClient = server.available();
+  if (newClient) {
+    IPAddress new_ip = newClient.remoteIP();
+    uint16_t new_port = newClient.remotePort();
+    ETHERNET_DEBUG_PRINTLN(
+        "New client available %u.%u.%u.%u:%u",
+        new_ip[0],
+        new_ip[1],
+        new_ip[2],
+        new_ip[3],
+        new_port);
+    if (client && client.connected()) {
+      IPAddress cur_ip = client.remoteIP();
+      uint16_t cur_port = client.remotePort();
+      ETHERNET_DEBUG_PRINTLN(
+          "Current client %u.%u.%u.%u:%u",
+          cur_ip[0],
+          cur_ip[1],
+          cur_ip[2],
+          cur_ip[3],
+          cur_port);
+      if (cur_ip == new_ip && cur_port == new_port) {
+        ETHERNET_DEBUG_PRINTLN("Ignoring duplicate client");
+        newClient.stop();
+        return 0;
+      }
+    }
+
+    deviceConnected = false;
+    if (client) {
+      ETHERNET_DEBUG_PRINTLN("Closing previous client");
+      client.stop();
+    }
+    _state = RECV_STATE_IDLE;
+    _frame_len = 0;
+    _rx_len = 0;
+    client = newClient;
+    ETHERNET_DEBUG_PRINTLN("Switched to new client");
+  }


Has this actually been tested with Android/Iphone/Meshcore-CLI for companion?
As a compile and test results in an immediate disconnect after first packet of data sent to the companion and it seems to be because of the code here. This doesn't seem consistant with the RAK examples. As any packet is received newClient will be created, and will point to same exact same socket# as the previous client object already in memory that was created from previous packet, so you hit the code that called newClient.stop(0 which actually wiill close newClient AND client sockets. Which disconnects the companion.

I think I have been able to rework the logic to make it work, as at least my the changes I have made to the logic flow seem to have fixed it. Will try to put a pull request in over on rgregg:rak-ethernet

cwichura · 2026-05-15T20:53:27Z

@rgregg As an alternative to MESH_PACKET_LOGGING, add support for the Ethernet module to the KISS firmware? Then we could run pyMC_repeater in a container/VM and have it connect remotely over Ethernet to the LoRa modem.

Also, do you have builds of this in its current state available online anywhere? If so, I'd be happy to try testing it on my RAK Ethernet MQTT Gateway kit. Thanks.

# Conflicts: # examples/companion_radio/main.cpp

EthernetServer::available() returns any socket with data, including the already-connected client's socket. The companion path then called stop() on what it thought was a duplicate client, closing the shared socket and disconnecting the companion after the first packet. Switch both SerialEthernetInterface and EthernetCLI to server.accept(), which only returns newly-accepted sockets. Removes the IP/port duplicate detection in the companion path (no longer reachable) and the same-socket early-return in the CLI path. Reported by mcode6726 on PR meshcore-dev#1983.

rgregg · 2026-05-18T21:20:49Z

@mcode6726 — Thanks for catching the companion disconnect, I've mostly tested the repeater firmware which didn't have the same bug. I've adjusted both paths to use server.accept() instead as a better call pattern.

@liamcottle — all of your round-2 feedback plus oltaco's nits have been addressed in earlier commits, and this latest fix resolves the companion bug. Ready for another look when you have time.

AcidWizard · 2026-06-20T02:22:24Z

Whats needed for this to be implemented? I want to use something similar to this but with an esp32-Olimex-POE board so using this as a base would be great, but if it will not be merged than I will continue on looking at a Raspberry Pi + normal MC device combination to put up on the roof.

If programming help is needed I am available as well, I however do not own any RAK modules right now. If needed I can acquire some.

# Conflicts: # docs/faq.md # examples/companion_radio/main.cpp

rgregg · 2026-06-20T21:45:08Z

@AcidWizard - I'm not really sure tbh. I've been running this firmware on my own repeater and companion nodes for a while, everything has been working great for me. I'd love to get this merged, it seems like there is sufficient interest in supporting it, but I haven't from the maintainers in several months.

Drasli-Tana · 2026-06-23T13:48:29Z

So I've tested a bit with the repeater firmware, on a RAK4631microcontroller paired with a RAK 13800 Ethernet module. Everything seems to be working fine for now using DHCP, commands work the same way the CLI does.

It might be useful to later store network configuration in node memory instead of relying on values set at compile time when using a static IP, to avoid having to reflash everything if that config has to change afterwards.

rgregg · 2026-06-28T05:27:35Z

@liamcottle — another nudge on this when you have time. Since your last review, all of your round-2 feedback is in (the ETH_* → ETHERNET_* rename, serial_interface.loop() naming, the build-env names), along with oltaco's nits and the companion-disconnect fix using server.accept() on both paths.

I've also merged up to current upstream/dev, so it's mergeable with no conflicts. It's had some outside testing now too — @Drasli-Tana confirmed the repeater firmware working on RAK4631 + RAK13800 over DHCP, and I've been running it on my own repeater and companion nodes for a few months without issues.

Your CHANGES_REQUESTED is the only thing holding up the review decision at this point. Happy to fix anything else you spot, but I think it's ready for another look.

rgregg · 2026-07-06T16:52:31Z

@ripplebiz I am hoping to get your read on this one when you have a moment -- or any other maintainer.

Quick status: all of @liamcottle's review feedback from the earlier rounds is in (the ETHERNET_* rename, the serial_interface.loop() naming, and the build-env changes), CI is green, and the branch is mergeable. It's also had independent hardware validation beyond my own nodes, @Drasli-Tana tested the repeater firmware on a RAK4631 + RAK13800 over DHCP and reported everything working.

The main reason I'm tagging you: there are now two overlapping Ethernet PRs on the bench and I'd like a steer on which one you'd prefer to take forward so we're not duplicating effort:

Support for RAK ethernet module #1983 (this PR): base RAK Ethernet module support for repeater + companion, which I've been running in production for a while.
Add RAK4631 / RAK10720 PoE + Ethernet companion support (W5100S/RAK13800) 🤖🤖 #2679 (@1sthandy): RAK4631/RAK10720 PoE + Ethernet companion support, which covers similar hardware and would arguably sit cleanly on top of this base once it lands.

I'm happy to go whichever direction makes the most sense to you, either get this merged as the foundation and coordinate #2679 on top, consolidate into one, or adjust scope. Just let me know your preference and I'll run with it. Thanks!

1sthandy · 2026-07-07T19:04:51Z

@rgregg thanks for teeing this up so clearly. From my side I'm fully on board with your suggested direction: land #1983 as the Ethernet foundation, and I'll rebase the PoE-specific parts of #2679 on top of it.

The PoE handling (W5100S power/reset sequencing, no-sleep, boot-voltage bypass, deferred bring-up) is largely transport-independent, so it should port cleanly onto your base — and it would apply to the repeater/room-server variants too, not just the companion.

Happy to coordinate whenever #1983 merges. @ripplebiz — a steer here would be much appreciated.

ripplebiz

Happy to merge, if you can attend to merge conflicts.

# Conflicts: # examples/companion_radio/main.cpp

rgregg · 2026-07-14T06:13:17Z

Thanks @ripplebiz - I've pushed a fix for the merge conflict and validated the PR functions as expected.

…sport - New WITH_ESP32_ETHERNET transport option for companion_radio (ESP32 / arduino core 3.x): brings up ETH.h W5500-over-SPI and reuses SerialWifiInterface, since WiFiServer/WiFiClient are NetworkServer/ NetworkClient aliases there. DHCP by default, optional ETH_STATIC_* build flags. Distinct from the nRF52 ETHERNET_ENABLED flag (PR #1983), which selects the RAK13800 SerialEthernetInterface implementation. - New variant waveshare_esp32s3_eth: Waveshare ESP32-S3-ETH board (W5500 on GPIO 9-14, PoE power option) + external Core1262 SX1262 module, RXEN-style RF switch per waveshare_rp2040_lora (SX126X_DIO2_AS_RF_SWITCH + SX126X_RXEN). Uses pioarduino platform like esp32c6_base. Envs: companion_radio_eth, repeater, room_server. Hardware-tested: DHCP + companion protocol over TCP.

enigmaspb · 2026-07-19T10:06:54Z

Hello @rgregg need some fix for you PR please see #2985

meshcore-dev#1983 landed a generic RAK4631 Ethernet base (repeater/room_server/companion envs, single-client SerialEthernetInterface, EthernetCLI telnet CLI) and independently added the same WB_IO2 rail-power fix we found for PoE boot. Layer the remaining PoE-specific delta on top of it instead of duplicating: - W5100SPoE: drop the now-redundant WB_IO2 early-ctor code (covered by meshcore-dev#1983's own constructor), keep only the early W5100S RST release and the bit-bang activation/VERSIONR check. - SerialEthernetInterface: add PoE-safe deferred bring-up (Ethernet.init/ begin() moved out of begin() into loop(), gated by an _hwReady flag, so the disruptive PHY soft-reset + DHCP can't collapse the marginal PoE supply at cold start) and bounded DHCP with a static-IP fallback. - EthernetCLI: same deferral (vTaskDelay before hardware bring-up) and bounded DHCP + static fallback for the repeater/room_server telnet path. - platformio.ini: add RAK_4631_{repeater,room_server,companion_radio} _ethernet_poe envs extending meshcore-dev#1983's _ethernet envs with WITH_W5100S_POE. Verified: all three new _poe envs build, plus the plain _ethernet envs and non-Ethernet variants (no cross-variant breakage). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The commented-out debug flag still referenced meshcore-dev#1983's original macro name (ETHERNET_DEBUG_LOGGING). SerialEthernetInterface.h now checks ETH_DEBUG_LOGGING after the merge with our multi-client/PoE-deferred implementation, so the comment was stale and enabling it would have done nothing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

rgregg marked this pull request as ready for review March 9, 2026 21:57

Copilot AI review requested due to automatic review settings March 9, 2026 21:57

Copilot started reviewing on behalf of rgregg March 9, 2026 21:58 View session

Copilot AI reviewed Mar 9, 2026

View reviewed changes

rgregg force-pushed the rak-ethernet branch 2 times, most recently from 3c57a33 to 12a4f4b Compare March 9, 2026 22:54

rgregg changed the base branch from main to dev March 11, 2026 02:36

rgregg and others added 2 commits March 10, 2026 20:43

rgregg force-pushed the rak-ethernet branch from 12a4f4b to aea64e1 Compare March 11, 2026 03:46

rgregg mentioned this pull request Mar 11, 2026

Support for Ethernet on RAK-based boards (e.g., RAK4631) #646

Closed

Add Ethernet documentation for RAK4631 ETH support

ffe0853

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

liamcottle requested changes Mar 11, 2026

View reviewed changes

Updates based on PR review feedback from liamcottle

3e9ceba

rgregg requested a review from liamcottle March 11, 2026 05:44

liamcottle requested changes Mar 11, 2026

View reviewed changes

Merge upstream/dev into rak-ethernet

eba2446

Resolve conflicts: keep both Ethernet CLI and SenseCAP power-off button code in repeater, keep both Ethernet docs and power management CLI docs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

mcode6726 reviewed May 6, 2026

View reviewed changes

rgregg added 2 commits May 18, 2026 20:57

Merge remote-tracking branch 'upstream/dev' into rak-ethernet

87bed49

# Conflicts: # examples/companion_radio/main.cpp

cwichura mentioned this pull request Jun 3, 2026

Add RAK4631 / RAK10720 PoE + Ethernet companion support (W5100S/RAK13800) 🤖🤖 #2679

Open

Merge remote-tracking branch 'upstream/dev' into rak-ethernet

a206f3e

# Conflicts: # docs/faq.md # examples/companion_radio/main.cpp

liamcottle requested a review from ripplebiz June 22, 2026 07:59

Bjorkan mentioned this pull request Jun 23, 2026

Add support for RAK4631 WisMesh Ethernet Gateway firmware openhop-dev/openhop_modem#22

Merged

Drasli-Tana mentioned this pull request Jun 26, 2026

Observer firmware for WisMesh MQTT Gateway #2846

Open

mathisono mentioned this pull request Jun 30, 2026

no support for RAK 10720 hardware kit. #2855

Open

ripplebiz reviewed Jul 14, 2026

View reviewed changes

Merge remote-tracking branch 'upstream/dev' into rak-ethernet

16b76bd

# Conflicts: # examples/companion_radio/main.cpp

ripplebiz merged commit b55d69e into meshcore-dev:dev Jul 15, 2026
15 checks passed

This was referenced Jul 16, 2026

Add RAK13800 Ethernet Companion targets with multi-client TCP support #2929

Closed

Add RAK13800 Ethernet Companion targets with multi-client TCP support #2972

Open

rgregg mentioned this pull request Jul 19, 2026

Fix nRF52 builds broken by unconditional RAK Ethernet include #2989

Merged

Uh oh!

Uh oh!

Conversation

rgregg commented Mar 9, 2026

Ethernet support for examples

Integration and initialization

Build workflow updates

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rgregg commented Mar 11, 2026

Uh oh!

liamcottle left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rgregg commented Mar 11, 2026

Uh oh!

liamcottle left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

liamcottle Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

rgregg Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JDat commented Mar 11, 2026

Uh oh!

neopiccolorat commented Mar 11, 2026

Uh oh!

rgregg commented Mar 11, 2026

Uh oh!

JDat commented Mar 12, 2026

Uh oh!

rgregg commented Mar 13, 2026

Uh oh!

rgregg commented Mar 13, 2026

Uh oh!

JDat commented Mar 14, 2026

Uh oh!

rgregg commented Mar 14, 2026

Uh oh!

JDat commented Mar 14, 2026

Uh oh!

rgregg commented Apr 26, 2026

Uh oh!

cwichura commented May 6, 2026

Uh oh!

mcode6726 May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

mcode6726 May 6, 2026 •

edited

Loading

rgregg commented Jul 6, 2026 •

edited

Loading