diff --git a/HANDOFF.md b/HANDOFF.md index 9553329..6a824ad 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -1418,6 +1418,69 @@ Sektion einklappbar machen"). Zwei Schritte: `.listStyle(.sidebar)` an der `List` ergänzt, für den nativen macOS-Sidebar-Look. Live bestätigt ("sehr gut, bin sehr zufrieden"). +**M24: LAN-Scanner — "Aktionen"-Button, Traffic-Monitor pro Port + +Sparkline, ARP-Auflösungsbug gefixt** (2026-09-16). Drei Nutzerwünsche +in einer Runde: + +1. **"Aktionen"-Button statt Rechtsklick** ("der Rechtsklick ist nicht + eindeutig erkennbar oder intuitiv, verlager bitte alle Funktionen + des Rechtsklicks in den Button") — `.contextMenu` komplett entfernt, + derselbe `deviceMenu(for:)`-Inhalt (Feste IP zuweisen/entfernen, + Netzwerk-Tools, Rohdaten anzeigen) läuft jetzt über einen sichtbaren + `Menu`-Button ("•••", Label "Aktionen") hinter jeder Geräte-Zeile. +2. **Traffic-Monitor pro Port + Sparkline** ("ein Traffic-Monitor im + LAN-Scanner", danach "ein kleines Liniendiagramm der letzten 10 + Sekunden ... pro Port") — pro-*Gerät* geht nicht ohne RouterOS- + seitige Queue-Trees pro MAC (Nutzer selbst dagegen entschieden: + "Traffic pro PORT statt pro Gerät"), daher denselben bereits + gebauten `InterfaceTrafficMonitor` (Verbinden-Tab) wiederverwendet — + `DevicesViewModel` bekam eigene `startTrafficPolling`/ + `stopTrafficPolling` (3s-Takt, gleiches Muster wie + `ConnectViewModel`). Live-↓/↑-Zahl direkt neben jedem Port-Titel, + plus neuer `TrafficSample`-Typ (`Core/Models/InterfaceTraffic.swift`) + für eine nach echter Zeit (nicht fester Sample-Anzahl) auf 10 + Sekunden getrimmte Historie, gerendert als `Chart`/`LineMark` + (Swift Charts, `TrafficSparkline` in `DevicesView.swift`) ohne + Achsen — reiner Trend-Blick, die genaue Zahl steht ja daneben. +3. **Bug 34, dabei live gefunden:** ein Laptop an `ether4` (Traffic + sichtbar aktiv) erschien trotzdem unter "Unbekannter Port". Ursache: + RouterOS' `/ip arp`-Tabelle hielt für dieselbe MAC-Adresse zwei + Zeilen gleichzeitig — eine korrekte (`interface=ether4, + status=reachable`) und eine veraltete (`interface=bridge, + status=failed`, Überbleibsel von vor einem Netzwerkwechsel des + Geräts). `DevicesViewModel.buildDevices` baute `arpInterfaceByMAC` + bisher per blindem Überschreiben der letzten gesehenen Zeile auf — + welche Zeile "gewann" hing von der Router-internen Tabellen- + Reihenfolge ab, nicht von Korrektheit. Fix: `status=reachable` + gewinnt jetzt immer gegen jeden anderen Status, bei Gleichstand ein + konkreter Port gegen "bridge". Zwei neue Regressionstests + (`testReachableArpRowWinsOverStaleFailedRowForSameMAC`/ + `...RegardlessOfOrder`, letzterer prüft explizit, dass der Fix nicht + nur für die live beobachtete Reihenfolge zufällig funktioniert). + +**Nebenbefund beim Debuggen von Punkt 2, kein Code-Bug, aber ein +Betriebshinweis:** der Traffic-Monitor zeigte zunächst dauerhaft nichts +an — `InterfaceTrafficMonitor.fetchTraffic` scheiterte still (`try?`) +mit `untrustedSSHHostKey`. Ursache: der Router hatte seit dem letzten +Werksreset (2026-09-15) einen neuen SSH-Host-Key, aber da die Haupt- +verbindung dieser Session durchgehend über REST lief (M22-Fix), kam der +bereits vorhandene "Unbekannter SSH-Schlüssel"-Bestätigungsdialog nie +zum Zug — der lief bisher nur im SSH-*Fallback*-Pfad von +`ConnectionService.connect`. Dedizierte SSH-Verbindungen (Backup, +Netzwerk-Tools, Traffic-Monitor, Update, Werksreset) haben *keinen* +eigenen UI-Bestätigungspfad für einen neuen Host-Key, scheitern bei +einem Mismatch einfach still. Behoben durch `www-ssl` kurz deaktiviert +(erzwingt den SSH-Fallback-Pfad in der Haupt-Verbindung), Nutzer hat +den neuen Fingerprint einmalig über den bestehenden Dialog bestätigt +(`SSHHostKeyTrustStore` ist ein einziger, über `UserDefaults.standard` +geteilter Speicher — einmal dort vertraut gilt für jede dedizierte +SSH-Verbindung mit), danach `www-ssl` wieder aktiviert. **Bleibt ein +echter, noch offener Schwachpunkt:** falls der SSH-Host-Key sich künftig +nochmal ändert (z.B. nach einem weiteren Werksreset) UND REST zu diesem +Zeitpunkt bereits verbunden ist, würden dieselben dedizierten Dienste +wieder wortlos nichts tun, ohne Hinweis auf die Ursache — siehe +"Nächste Schritte". + ## Nächste Schritte 1. ~~M16: restliche `RouterOSSchemaCatalog.swift`-Sektionen übersetzen~~, @@ -1576,6 +1639,21 @@ Sektion einklappbar machen"). Zwei Schritte: DHCP-Netzwerk-Optionen zwei Hops entfernt), Klick auf Pool/Adresse bleibt bei der 1-Hop-Regel — beides wie erwartet bestätigt ("passt, live bestätigt"). +13. **Dedizierte SSH-Dienste scheitern still bei SSH-Host-Key-Mismatch, + solange REST verbindet** (siehe M24-Nebenbefund oben) — + `BackupService`/`NetworkToolsService`/`InterfaceTrafficMonitor`/ + `UpdateService`/`FactoryResetService` haben keinen eigenen + UI-Bestätigungspfad für einen neuen SSH-Host-Key, nur + `ConnectionService.connect`s SSH-*Fallback* zeigt den Dialog — und + der wird nie erreicht, solange REST erfolgreich verbindet. Ein + künftiger Host-Key-Wechsel (z.B. nach einem weiteren Werksreset) + würde also wieder zu wortlos leeren Ergebnissen führen (leere + Traffic-Anzeige, fehlschlagende Backups, etc.), ohne erkennbaren + Grund in der UI. Mögliche Fixes: diese Dienste bei + `untrustedSSHHostKey` einen eigenen Bestätigungsdialog zeigen + lassen, oder `ConnectionService` beim Verbinden zusätzlich (nicht + nur im Fallback-Fall) einmal den SSH-Host-Key prüfen/bestätigen + lassen, unabhängig davon, ob REST erfolgreich war. Gitea-Remote `origin` ist eingerichtet und wird laufend gepusht (siehe oben) — dieser Hinweis war veraltet, korrigiert am 2026-09-15. diff --git a/README.md b/README.md index 27e98e9..95a787b 100644 --- a/README.md +++ b/README.md @@ -153,6 +153,7 @@ nur die zugehörigen Passwörter liegen weiterhin im macOS-Schlüsselbund. | M21 | Zweisprachigkeit (DE/EN) auf alle fünf Tabs ausgerollt (Einrichten/Übersicht/LAN-Scanner/Sicherungen) | ✅ live verifiziert | | M22 | REST-Transport (M7) erstmals live gegen Hardware verifiziert, 4 Bugs gefunden+gefixt | ✅ live verifiziert | | M23 | Experte-Tab: Sektionsüberschriften prominenter+eingefärbt, einklappbar (Standard: zugeklappt) | ✅ live verifiziert | +| M24 | LAN-Scanner: "Aktionen"-Button statt Rechtsklick, Traffic-Monitor+Sparkline pro Port, ARP-Bug gefixt | ✅ live verifiziert | | — | LAN-Port-Konflikt-Prüfung + "Fertig"-Button (Einrichten) | 🔶 gebaut, Live-Test offen | Ausführlicher Stand inkl. aller gefundenen Bugs, offener Punkte und @@ -176,7 +177,7 @@ RouterOS/ │ │ │ ├── LanDevice.swift — ein Gerät im LAN-Scanner-Tab (Lease+ARP+Bridge-Host verschmolzen) │ │ │ ├── SavedRouter.swift — ein Eintrag in "Bekannte Router" (Host/Name/Standort) │ │ │ ├── PortConflict.swift — LAN-Port-Konflikt-Prüfung (Bridge/Adresse/DHCP-Client/PPPoE) -│ │ │ ├── InterfaceTraffic.swift — ein Live-Durchsatz-Sample für die Traffic-Anzeige +│ │ │ ├── InterfaceTraffic.swift — ein Live-Durchsatz-Sample + TrafficSample (10s-Sparkline-Historie, LAN-Scanner) │ │ │ ├── NetworkToolResult.swift — Rohausgabe von Ping/Traceroute/DNS-Auflösung │ │ │ ├── PortScanResult.swift — Ergebnis eines Port-Scans, ein Eintrag pro Port │ │ │ └── RouterOSModels.swift — Credentials, DeviceInfo, RouterBoardInfo, PackageUpdateInfo, Fehler diff --git a/RouterOSAssistant/Core/Localization/L10n.swift b/RouterOSAssistant/Core/Localization/L10n.swift index 53c94e9..85a245e 100644 --- a/RouterOSAssistant/Core/Localization/L10n.swift +++ b/RouterOSAssistant/Core/Localization/L10n.swift @@ -835,6 +835,7 @@ enum L10n { "Keine Geräte": "No Devices", "Führe Netzwerk-Test aus…": "Running network test…", "Neu scannen": "Rescan", + "Aktionen": "Actions", "Feste Zuweisung entfernen": "Remove Static Assignment", "Feste IP zuweisen": "Assign Static IP", "Kein DHCP-Lease — feste Zuweisung hier nicht möglich": "No DHCP lease — static assignment not possible here", diff --git a/RouterOSAssistant/Core/Models/InterfaceTraffic.swift b/RouterOSAssistant/Core/Models/InterfaceTraffic.swift index 63bd687..36ebf99 100644 --- a/RouterOSAssistant/Core/Models/InterfaceTraffic.swift +++ b/RouterOSAssistant/Core/Models/InterfaceTraffic.swift @@ -10,3 +10,14 @@ struct InterfaceTraffic: Equatable { var isActive: Bool { rxBitsPerSecond > 0 || txBitsPerSecond > 0 } } + +/// One timestamped throughput reading, kept in a short rolling per-port history so the +/// LAN-Scanner's port headers can show a small sparkline of the last few seconds, not just the +/// current instantaneous value (Nutzerwunsch: "ein kleines Liniendiagramm der letzten 10 Sekunden +/// ... pro port"). Timestamped (not just appended in order) so trimming to "last 10 seconds" stays +/// correct even if a poll tick is ever delayed or skipped, rather than assuming a fixed cadence. +struct TrafficSample: Identifiable { + let id = UUID() + let timestamp: Date + let totalBitsPerSecond: Int +} diff --git a/RouterOSAssistant/Features/Devices/DevicesView.swift b/RouterOSAssistant/Features/Devices/DevicesView.swift index f43da96..a1b9d97 100644 --- a/RouterOSAssistant/Features/Devices/DevicesView.swift +++ b/RouterOSAssistant/Features/Devices/DevicesView.swift @@ -1,3 +1,4 @@ +import Charts import SwiftUI /// "LAN-Scanner" tab: one table per physical Ethernet/WLAN port, each listing the @@ -56,14 +57,40 @@ struct DevicesView: View { } else { DeviceColumnHeader(appLanguage: appLanguage) ForEach(group.devices) { device in - DeviceRow(device: device, appLanguage: appLanguage) - .contextMenu { + HStack(spacing: 4) { + DeviceRow(device: device, appLanguage: appLanguage) + Spacer() + // Per explicit request: right-click alone wasn't + // discoverable ("nicht eindeutig erkennbar oder + // intuitiv") — every action that used to live only in + // `.contextMenu` now lives in this visible button + // instead, same `deviceMenu(for:)` content reused. + Menu { deviceMenu(for: device) + } label: { + Label(L10n.t("Aktionen", appLanguage), systemImage: "ellipsis.circle") + .labelStyle(.iconOnly) } + .menuStyle(.borderlessButton) + .fixedSize() + .help(L10n.t("Aktionen", appLanguage)) + } } } } header: { - Text("\(group.title) (\(group.devices.count))") + HStack(spacing: 8) { + Text("\(group.title) (\(group.devices.count))") + if let traffic = viewModel.portTraffic[group.id] { + Spacer() + TrafficSparkline(history: viewModel.portTrafficHistory[group.id] ?? []) + Label( + Self.formatTraffic(traffic), + systemImage: traffic.isActive ? "arrow.up.arrow.down.circle.fill" : "arrow.up.arrow.down.circle" + ) + .font(.caption2) + .foregroundStyle(traffic.isActive ? .green : .secondary) + } + } } } } @@ -107,6 +134,18 @@ struct DevicesView: View { await viewModel.load() } } + .onAppear { + if let credentials = connectionService.credentials { + viewModel.startTrafficPolling(credentials: credentials) + } + } + .onChange(of: connectionService.state) { _, newState in + if case .connected = newState, let credentials = connectionService.credentials { + viewModel.startTrafficPolling(credentials: credentials) + } else { + viewModel.stopTrafficPolling() + } + } .withStaticAssignmentDialogs( viewModel: viewModel, appLanguage: appLanguage, @@ -117,6 +156,23 @@ struct DevicesView: View { } } + /// Same unit-suffix style RouterOS itself reports live traffic in (`SSHTransport. + /// parseBitsPerSecond`'s doc comment: "50.7kbps", "34.0kbps") — kept consistent instead of + /// inventing a different display format for the same underlying number. + private static func formatTraffic(_ traffic: InterfaceTraffic) -> String { + "↓\(formatBitsPerSecond(traffic.rxBitsPerSecond)) ↑\(formatBitsPerSecond(traffic.txBitsPerSecond))" + } + + private static func formatBitsPerSecond(_ bitsPerSecond: Int) -> String { + let units: [(suffix: String, divisor: Double)] = [ + ("Gbps", 1_000_000_000), ("Mbps", 1_000_000), ("kbps", 1_000) + ] + for unit in units where Double(bitsPerSecond) >= unit.divisor { + return String(format: "%.1f%@", Double(bitsPerSecond) / unit.divisor, unit.suffix) + } + return "\(bitsPerSecond)bps" + } + @ViewBuilder private func deviceMenu(for device: LanDevice) -> some View { if device.hasLease { @@ -286,6 +342,37 @@ private extension View { } } +/// Small sparkline next to each port header — last-10-seconds rolling window from +/// `DevicesViewModel.portTrafficHistory` (Nutzerwunsch: "ein kleines Liniendiagramm der letzten +/// 10 Sekunden ... pro Port"). No axes/labels by design — a trend glance, not a readable chart; +/// the exact current numbers are already shown right next to it via the ↓/↑ text. Stays an empty +/// fixed-size placeholder (not collapsing/disappearing) with fewer than two points, so the row +/// layout doesn't jump around during the first couple of poll ticks after opening the tab. +private struct TrafficSparkline: View { + let history: [TrafficSample] + + var body: some View { + Group { + if history.count >= 2 { + Chart(history) { sample in + LineMark( + x: .value("Zeit", sample.timestamp), + y: .value("Traffic", sample.totalBitsPerSecond) + ) + .interpolationMethod(.linear) + .foregroundStyle(Color.accentColor) + } + .chartXAxis(.hidden) + .chartYAxis(.hidden) + .chartYScale(domain: 0...max(history.map(\.totalBitsPerSecond).max() ?? 1, 1)) + } else { + Color.clear + } + } + .frame(width: 50, height: 16) + } +} + /// Column widths shared between the header and each row so they line up like a real table. private enum DeviceColumn { static let icon: CGFloat = 16 diff --git a/RouterOSAssistant/Features/Devices/DevicesViewModel.swift b/RouterOSAssistant/Features/Devices/DevicesViewModel.swift index 997e285..cf0d3c4 100644 --- a/RouterOSAssistant/Features/Devices/DevicesViewModel.swift +++ b/RouterOSAssistant/Features/Devices/DevicesViewModel.swift @@ -32,6 +32,21 @@ final class DevicesViewModel: ObservableObject { /// `PortScanner`, not through the router — see its own doc comment for why. @Published var portScanResult: PortScanResult? + /// Live per-port throughput (Nutzerwunsch: "ein Traffic-Monitor im LAN-Scanner zu den + /// einzelnen Geräten" — per-device counters aren't something RouterOS exposes natively + /// without setting up queue trees per MAC, so this reuses the same per-*port* live monitor + /// already built for the Verbinden-Tab instead; keyed by `DevicePortGroup.id` (the physical + /// interface name), not by device). "unbekannt" (devices RouterOS couldn't resolve onto a + /// real port) is never polled — it isn't a real interface. + @Published private(set) var portTraffic: [String: InterfaceTraffic] = [:] + /// Rolling last-10-seconds history per port, for the small sparkline next to each port + /// header (Nutzerwunsch: "ein kleines Liniendiagramm der letzten 10 Sekunden ... pro Port"). + /// Trimmed by actual elapsed time each tick, not by a fixed sample count, so it stays a true + /// "last 10 seconds" window even if a poll tick is ever late. + @Published private(set) var portTrafficHistory: [String: [TrafficSample]] = [:] + private let trafficMonitor = InterfaceTrafficMonitor() + private var trafficPollingTask: Task? + private let connectionService: ConnectionService private let backupService: BackupService private let networkToolsService: NetworkToolsService @@ -46,6 +61,44 @@ final class DevicesViewModel: ObservableObject { self.networkToolsService = networkToolsService } + /// Same 3s cadence/reasoning as `ConnectViewModel.startTrafficPolling` — re-reads + /// `portGroups` every tick so a newly-appearing port (e.g. a VLAN interface added via the + /// Setup wizard while this tab is open) gets picked up without restarting the poll. + func startTrafficPolling(credentials: RouterOSCredentials) { + stopTrafficPolling() + trafficPollingTask = Task { + while !Task.isCancelled { + let names = portGroups.map(\.id).filter { $0 != "unbekannt" } + if !names.isEmpty { + let traffic = await trafficMonitor.fetchTraffic(interfaceNames: names, for: credentials) + if !Task.isCancelled { + portTraffic = traffic + appendTrafficHistory(traffic, at: Date()) + } + } + try? await Task.sleep(for: .seconds(3)) + } + } + } + + private func appendTrafficHistory(_ traffic: [String: InterfaceTraffic], at timestamp: Date) { + let cutoff = timestamp.addingTimeInterval(-10) + for (name, sample) in traffic { + var history = portTrafficHistory[name] ?? [] + history.append(TrafficSample(timestamp: timestamp, totalBitsPerSecond: sample.rxBitsPerSecond + sample.txBitsPerSecond)) + history.removeAll { $0.timestamp < cutoff } + portTrafficHistory[name] = history + } + } + + func stopTrafficPolling() { + trafficPollingTask?.cancel() + trafficPollingTask = nil + portTraffic = [:] + portTrafficHistory = [:] + Task { await trafficMonitor.disconnect() } + } + func runPing(for device: LanDevice) { runNetworkTool(title: "Ping: \(device.ipAddress)") { [networkToolsService] credentials in try await networkToolsService.ping(address: device.ipAddress, for: credentials) @@ -277,11 +330,36 @@ final class DevicesViewModel: ObservableObject { // Fallback: ARP's "interface" field — exact if that interface isn't a bridge, otherwise // only "somewhere on this bridge" (resolved further by the bridge host table above when - // available). + // available). RouterOS can hold MULTIPLE ARP rows for the same MAC at once (live- + // confirmed: a device on a standalone port like "ether4" still had a second, stale + // "status=failed" row for an old address on "interface=bridge", left over from before it + // moved networks) — blindly keeping the last row seen made the resolution depend on + // table order, not correctness, and could silently overwrite a working resolution with + // a dead one (this device fell into "Unbekannter Port" despite a perfectly good + // "reachable" ether4 row existing). Now scored: a "reachable" row always wins over any + // other status, tie-broken by preferring a non-bridge (more specific) interface, so a + // genuinely ambiguous case still prefers whatever's most precise. var arpInterfaceByMAC: [String: String] = [:] + var arpStatusByMAC: [String: String] = [:] for item in arpEntries { guard let mac = item.fields["mac-address"]?.lowercased(), let iface = item.fields["interface"] else { continue } - arpInterfaceByMAC[mac] = iface + let status = item.fields["status"] ?? "" + guard let existingStatus = arpStatusByMAC[mac] else { + arpInterfaceByMAC[mac] = iface + arpStatusByMAC[mac] = status + continue + } + let isNewReachable = status == "reachable" + let isExistingReachable = existingStatus == "reachable" + if isNewReachable && !isExistingReachable { + arpInterfaceByMAC[mac] = iface + arpStatusByMAC[mac] = status + } else if isNewReachable == isExistingReachable, + let existingIface = arpInterfaceByMAC[mac], + bridgeNames.contains(existingIface), !bridgeNames.contains(iface) { + arpInterfaceByMAC[mac] = iface + arpStatusByMAC[mac] = status + } } // Last resort: the DHCP server's own configured interface — network-level only, since a diff --git a/RouterOSAssistantTests/DevicesViewModelTests.swift b/RouterOSAssistantTests/DevicesViewModelTests.swift index 78566a3..c511f31 100644 --- a/RouterOSAssistantTests/DevicesViewModelTests.swift +++ b/RouterOSAssistantTests/DevicesViewModelTests.swift @@ -54,6 +54,54 @@ final class DevicesViewModelTests: XCTestCase { XCTAssertTrue(devices[0].isExactPort) } + /// Live-confirmed (2026-09-16): RouterOS' `/ip arp` table held two rows for the same MAC at + /// once — a "reachable" one on the device's real standalone port, and a stale "failed" one + /// left over from an earlier network on "bridge". The old code built `arpInterfaceByMAC` by + /// blindly overwriting with whatever row came last, so which one "won" depended on array + /// order, not correctness — this device fell into "Unbekannter Port" despite the working + /// row existing. Reproduces that exact shape (stale bridge row listed AFTER the reachable + /// direct-port row, matching the live capture) and asserts the reachable, more specific + /// port wins regardless of order. + func testReachableArpRowWinsOverStaleFailedRowForSameMAC() { + let devices = DevicesViewModel.buildDevices( + leases: [item([ + "address": "192.168.4.254", "mac-address": "AC:91:A1:04:BB:08", + "host-name": "Laptop", "server": "dhcp_ether4" + ])], + arpEntries: [ + item(["address": "192.168.4.254", "mac-address": "AC:91:A1:04:BB:08", "interface": "ether4", "status": "reachable"]), + item(["address": "192.168.88.252", "mac-address": "AC:91:A1:04:BB:08", "interface": "bridge", "status": "failed"]) + ], + bridgeHosts: [], + interfaces: [item(["name": "bridge", "type": "bridge"]), item(["name": "ether4", "type": "ether"])], + dhcpServers: [item(["name": "dhcp_ether4", "interface": "ether4"])] + ) + + XCTAssertEqual(devices[0].resolvedPort, "ether4") + XCTAssertTrue(devices[0].isExactPort) + XCTAssertNotEqual(devices[0].displayPort, "unbekannt") + } + + /// Same shape, rows in the opposite order (reachable row listed second) — the fix must not + /// just happen to work for the one order seen live. + func testReachableArpRowWinsOverStaleFailedRowRegardlessOfOrder() { + let devices = DevicesViewModel.buildDevices( + leases: [item([ + "address": "192.168.4.254", "mac-address": "AC:91:A1:04:BB:08", + "host-name": "Laptop", "server": "dhcp_ether4" + ])], + arpEntries: [ + item(["address": "192.168.88.252", "mac-address": "AC:91:A1:04:BB:08", "interface": "bridge", "status": "failed"]), + item(["address": "192.168.4.254", "mac-address": "AC:91:A1:04:BB:08", "interface": "ether4", "status": "reachable"]) + ], + bridgeHosts: [], + interfaces: [item(["name": "bridge", "type": "bridge"]), item(["name": "ether4", "type": "ether"])], + dhcpServers: [item(["name": "dhcp_ether4", "interface": "ether4"])] + ) + + XCTAssertEqual(devices[0].resolvedPort, "ether4") + } + func testLeaseNotInStaticMacSetIsDynamic() { // Confirmed live on a real hEX: "/ip dhcp-server lease print terse" never emits a // "dynamic" key at all, in either state — reading fields can't distinguish static from