Build the radio model, and build it for Windows - #4
Merged
Merged
Conversation
The radio model sits between an emulated MCU and the engine, and every emulated node needs one - so a bundle without it ships two emulators that cannot be driven. This file could not be built for Windows: it included <sys/un.h> unconditionally and used read/write/poll on socket handles, none of which mingw has. Confined to the same five-line compat block bridge/main.cpp already uses, plus WSAPoll for waiting on two sockets. Windows takes the TCP half only - its AF_UNIX is unreachable without <sys/un.h>, and the simulator already asks for ":0" there for both emulators - and says so rather than listening nowhere. Includes the TCP transport and the console-message fix from #3, which this supersedes.
Nothing built the radio model. build.sh compiled bridge/main.cpp into every role and left bridge/radioserver.cpp alone, so the one binary an emulated node cannot start without was built by hand or not at all - and every shipped bundle so far has been the latter. It needs neither MeshCore nor Crypto, only the chip model beside it, so those two checkouts are no longer demanded for this target. Built from this tree rather than from the simulator so a native node and an emulated one keep the same VirtualSX1262.
A13xB0
pushed a commit
to MeshBench/meshbench
that referenced
this pull request
Aug 14, 2026
Every emulated node looks up radioserver before it looks up either emulator, and no bundle has ever contained one: nothing built it, no release published it, and no packaging job staged it. 0.0.1 through 0.0.3 shipped a QEMU and a Renode that nothing could drive, with a README saying emulated boards worked out of the box. All three jobs now build it from meshcore-native - the repository the chip model lives in, so a native node and an emulated one stay the same VirtualSX1262 - and a failure is fatal rather than a warning. The way this stayed hidden for three releases was a green build. lookupTool also learns the versioned renode_*-portable layout by glob. Linux and macOS bridge that with a symlink; a zip cannot carry one, so Windows shipped a Renode two directories from anywhere the search looked. Needs MeshBench/meshcore-native#4, which is what builds radioserver and what makes it compile for Windows at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every emulated node — ESP32 or nRF52, on any platform — starts by looking up
radioserver. Nothing built it:build.shcompiledbridge/main.cppinto each role and never touchedbridge/radioserver.cpp, no release published it, and no MeshBench bundle staged it. Unpacking the 0.0.3 artifacts confirms it: zeroradioserverentries in the Linux tarball or the Windows zip, beside a QEMU and a Renode that therefore cannot be driven.bridge/radioserver.cpp— builds for Windows now. It included<sys/un.h>unconditionally and usedread/write/pollon socket handles, none of which mingw has. Confined to the same compat blockbridge/main.cppalready uses, plusWSAPoll. Windows gets the TCP half only: itsAF_UNIXis unreachable without<sys/un.h>, and the simulator already asks for:0there for both emulators, so the missing half was never going to be used. It says so rather than listening nowhere.build.sh— aradioservertarget. Two objects and a link: it needs neither MeshCore nor Crypto, so this target no longer demands those checkouts, which is what lets a packaging job build it from this repo alone.This includes the TCP transport and the console-message fix from #3, so #3 can be closed in favour of this.
Verified here:
-lws2_32), throughbuild.shfor bothlistening on 127.0.0.1:<port>— the line the simulator parses back — accepts a connection, serves CS assert / transfer / BUSY / IRQ / CS release, and exits 0 reporting its transaction countMESHCORE, and still reports an unknown roleNot verified: the Windows binary has not been run on Windows, only cross-compiled and linked.