2 Commits

Include renames

Author	SHA1	Message	Date
octoturge	c6cf9bcb5e	Report discovered printers to the cloud, off by default ... The gateway could already find printers; only a human reading a terminal could see the result. So adding a printer in the web console still began with walking to a machine to read its IP address off the screen. Now a background task scans on a timer and sends a `discovered_printers` frame. It cannot finish the job - the credential is on that screen and no probe can read it - but it removes the address, the serial and the guesswork about which vendor the thing is. OFF by default, which is the load-bearing part of this commit. A /24 sweep is 254 TLS handshakes and up to three HTTP requests per host, and nothing watching can tell that from a port scan; on a corporate network, being indistinguishable from a port scan is itself the problem. A gateway that did this by default would scan networks its operator never meant to point it at, and the first they would hear of it is from their own security team. So: - `discovery.enabled` is false unless set, per gateway, in that gateway's own config. The cloud cannot switch it on. A setting whose whole purpose is to bound what this process does to the local network has to be decided where that network is understood, which is not in a data centre. - `subnets` is explicit, never derived from this host's interfaces, so a second NIC, a VPN or a container bridge cannot widen the sweep. Anything wider than a /24 is still refused, now at config-import time rather than when the timer first fires. - A flag that is neither `true` nor `false` is an error, not a shrug. The two readings of a typo are not equally safe. - Naming a subnet without setting `enabled` scans nothing - the safe reading of an incomplete instruction - and `enabled` with nowhere to look is refused as the mistake it is. - The env var can switch it *off* over a file that enables it, which is the direction that has to work: a Proxy Box's config is signed in the cloud, so an operator who finds their gateway probing cannot just edit it. What a scheduled scan will not do, unlike the example CLI: send `M115`. Opening a serial port toggles DTR, which reboots an Arduino-based board and ruins a print in progress. The example can do it behind `--yes-reset-the-printer` because a human is standing there; a timer has nobody to ask, so it does not get the option and reads sysfs instead. Two things that took more care than expected: `Scan::looked()`. An empty report means "this gateway looked and its network has no unconfigured printers", so sending one after every probe failed would state something untrue about the farm. A partial failure is still evidence, though - withholding a good sweep because a container can never bind SSDP would suppress it forever - so the test is "did anything succeed", not "did everything". `fleet::configured()` reads the fleet file at parse level rather than through `load`, because the entry it most needs to recognise is the one `load` refuses: a printer discovery suggested, pasted in, with the access code not yet typed in. Re-offering that printer as a fresh find is noise at the one moment the operator is mid-way through adding it. Verified against the real LAN: a sweep found both printers by TLS certificate with correct serials and no credentials, and the frame it produced validates against the backend's EdgeClientMessageSchema. The `wire` subcommand on the example prints exactly that frame, and the capture is pinned as a backend fixture. SSDP remains untestable here - this container is a router hop from the printers and multicast does not cross one.	2026-10-19 08:21:30 +00:00
octoturge	da28597eeb	Report the OctoPrint API as what it is, and let the operator name it ... Reporting a detected printer as `prusa_link` asserted a product nothing on the wire mentions. What a probe observes is that something speaks the OctoPrint REST API; PrusaLink is one implementation of it, OctoPrint itself is another, and without a credential the two are indistinguishable - every PrusaLink identity endpoint requires digest auth. So discovery now reports `vendor = "octoprint"`, the protocol it actually saw, and carries `ambiguous_with` so the rendered entry prints a comment offering `prusa_link` directly above the `vendor` line. Changing it is a one-word edit in the file the operator is already pasting into, which is the right place for a question only they can answer. The exception is a body that names itself: `/api/version`'s `text` field reads "PrusaLink 0.7.0" or "OctoPrint 1.9.3", so on the rare unauthenticated 200 the answer is known and no choice is offered. For that to mean anything, `octoprint` had to become a vendor `fleet.rs` accepts - otherwise discovery printed a block that would not load. It maps to the same client as `prusa_link`, because they speak the same API, with an `OctoPrintFlavour` recording which. The flavour is stored now, while the client is still a stub, precisely because no probe can settle it: it is the operator's answer, and without somewhere to keep it the real client would have to ask them a second time. `PrusaLinkPrinter` is accordingly now `OctoPrintPrinter` - one client for the API family - since a struct called PrusaLink holding a flavour that says "Generic" is a contradiction someone would later have to unpick. **Found by the new test, and the reason it exists:** `fleet::load` did *not* reject an entry whose credential was blank. `require_field` took an `Option`, so `access_code = ""` arrived as `Some("")` and loaded happily - which falsified the claim this feature was built on, that printing a block with an empty credential is safe because pasting it in unfinished fails loudly at startup. It does now. An empty credential is not a usable one; it only moves the failure somewhere worse, where a Bambu printer is refused at MQTT and a PrusaLink one 401s on every poll with nothing saying the field is blank. This is the same trap as `??`-instead-of-`||` on an environment variable that ships empty, which the backend's `auth/edge_secret.ts` and `s3/index.ts` both document; it bites identically on a TOML key. tests/discovery_to_fleet.rs is new and closes the loop: discovery and fleet are coupled by nothing but a string, unit tests on either side cannot catch a drift between them, and the symptom of a drift is an operator pasting in exactly what they were told to and the gateway refusing to start. It renders a candidate for every vendor, fills in the credential the way a human would, loads it for real, and checks the handle matches the vendor asked for - not merely that something loaded, since `octoprint` and `prusa_link` share a client and a mapping that collapsed them would still load and still be wrong. Verification: the Moonraker probe now runs end to end over real HTTP against a stand-in serving Moonraker's documented `/printer/info`, and correctly reports a klipper entry named from the returned hostname. Port 80 cannot be bound without root here, so the PrusaLink path is covered by a test that takes a real socket answering a real digest challenge - the one link unit tests on the classifier cannot reach, and the one PrusaLink is identified by.	2026-10-19 07:40:28 +00:00