kay/RouterOS
1
0
Fork 1
Code Issues 1 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Fix: CLI-Parser verlor 6 von 7 Interfaces auf echtem hEX-Gerät

Browse Source 
Kritischer Fund beim M6-Live-Test: RouterOSCliParser.parseInterfaces
splittete nur auf "\n", aber die SSH-Ausgabe eines echten hEX-Routers
trennt Zeilen anders -- alle Interface-Zeilen wurden zu EINER Zeile
zusammengefasst. Beim key=value-Parsen dieser einen Riesenzeile
überschrieb jedes Feld (name=, type=, ...) den vorherigen Wert, sodass
am Ende nur das letzte Interface im Text ("lo", Loopback) übrig blieb
-- mit den Feldwerten aller anderen Interfaces vermischt.

Folge: WAN-Schritt zeigte nur "lo" zur Auswahl, wodurch alle
WAN-Interface-Referenzen (NAT-Masquerade, ICMP-Regel, WAN-Block-Regel,
finale Anti-Spoofing-Regel) fälschlich auf "lo" statt den echten
WAN-Port zeigten. Auf diesem Testgerät blieb es folgenlos, weil RouterOS
schon eine vollständige eigene Standard-Firewall (defconf) mitbrachte,
die den echten Schutz weiterhin übernahm -- auf einem Gerät ohne
bestehende Firewall hätte das eine wirkungslose Firewall bedeutet, die
sich als aktiv ausgegeben hätte.

Fix: split(whereSeparator: \.isNewline) statt split(separator: "\n"),
robust gegen \n/\r/\r\n. Zusätzliches Sicherheitsnetz in SetupView:
Loopback-Interfaces werden aus allen WAN/LAN/VLAN-Auswahllisten
gefiltert, damit ein ähnlicher Parser-Fehler künftig nicht erneut zu
einer sinnlosen Interface-Auswahl führen kann. Regressionstest mit
realen \r\n-getrennten hEX-Daten ergänzt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW
This commit is contained in:
Kay
2026-09-12 20:17:26 +02:00
co-authored by Claude Sonnet 5
parent da5133245e
commit c1f9940eae
3 changed files with 37 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RouterOSAssistant/Core/Networking/RouterOSCliParser.swift
+7 -2
View File
@@ -6,7 +6,7 @@ enum RouterOSCliParser {
/// Parses `/system resource print` output (colon-separated "key: value" lines).
static func parseDeviceInfo(_ raw: String) -> RouterDeviceInfo {
var fields: [String: String] = [:]
for line in raw.split(separator: "\n") {
for line in raw.split(whereSeparator: \.isNewline) {
guard let colonIndex = line.firstIndex(of: ":") else { continue }
let key = String(line[line.startIndex..<colonIndex]).trimmingCharacters(in: .whitespaces)
let value = String(line[line.index(after: colonIndex)...]).trimmingCharacters(in: .whitespaces)
@@ -21,8 +21,13 @@ enum RouterOSCliParser {
}
/// Parses `/interface print terse` output (one line per interface, `key=value` pairs).
///
/// Splits on any newline-like character, not just "\n" — a real hEX device's SSH output
/// turned out not to split on bare "\n", collapsing every interface into a single "line"
/// whose repeated keys (name=, type=, ...) then overwrote each other in the fields
/// dictionary, leaving only the last interface (`lo`) in the result. Found via live testing.
static func parseInterfaces(_ raw: String) -> [NetworkInterface] {
raw.split(separator: "\n").compactMap { line in
raw.split(whereSeparator: \.isNewline).compactMap { line in
let fields = keyValues(from: String(line))
guard let name = fields["name"] else { return nil }
return NetworkInterface(
RouterOSAssistant/Features/Wizard/Steps/Setup/SetupView.swift
+12 -4
View File
@@ -21,11 +21,11 @@ struct SetupView: View {
} else {
switch viewModel.step {
case .wan:
WanStepView(viewModel: viewModel, availableInterfaces: connectionService.interfaces)
WanStepView(viewModel: viewModel, availableInterfaces: configurableInterfaces)
case .lan:
LanStepView(viewModel: viewModel, availableInterfaces: connectionService.interfaces)
LanStepView(viewModel: viewModel, availableInterfaces: configurableInterfaces)
case .vlan:
VlanStepView(viewModel: viewModel, availableInterfaces: connectionService.interfaces)
VlanStepView(viewModel: viewModel, availableInterfaces: configurableInterfaces)
case .wifi:
WifiStepView(viewModel: viewModel)
case .firewall:
@@ -37,9 +37,17 @@ struct SetupView: View {
}
}
.onAppear {
viewModel.prepareDefaults(from: connectionService.interfaces)
viewModel.prepareDefaults(from: configurableInterfaces)
}
}
/// Loopback is never something a person should pick as WAN/LAN/VLAN base interface —
/// excluded here (not just via defaults) so a parsing hiccup elsewhere can't offer it as
/// a selectable option, which on a real hEX device caused every WAN/firewall command to
/// silently reference "lo" instead of the real WAN port. Found via live testing.
private var configurableInterfaces: [NetworkInterface] {
connectionService.interfaces.filter { $0.type.lowercased() != "loopback" }
}
}
#Preview {
RouterOSAssistantTests/RouterOSCliParserTests.swift
+18
View File
@@ -34,4 +34,22 @@ final class RouterOSCliParserTests: XCTestCase {
XCTAssertFalse(interfaces[1].running)
XCTAssertTrue(interfaces[1].disabled)
}
/// Regression test for a real bug found on a physical hEX device: its SSH output didn't
/// split on bare "\n", collapsing every interface into one "line" whose repeated keys
/// (name=, type=, ...) overwrote each other, leaving only the last interface ("lo").
func testParseInterfacesHandlesCarriageReturnLineEndings() {
let raw = [
"0 R name=ether1 default-name=ether1 type=ether mtu=1500",
"1 RS name=ether2 default-name=ether2 type=ether mtu=1500",
"5 R comment=defconf name=bridge type=bridge mtu=auto",
"6 R name=lo type=loopback mtu=65536"
].joined(separator: "\r\n")
let interfaces = RouterOSCliParser.parseInterfaces(raw)
XCTAssertEqual(interfaces.count, 4)
XCTAssertEqual(interfaces.map(\.name), ["ether1", "ether2", "bridge", "lo"])
XCTAssertEqual(interfaces.map(\.type), ["ether", "ether", "bridge", "loopback"])
}
}