luci-mod-network: use device-specific MTU limits

[dormancygrace]

Description

Use the per-device min_mtu and max_mtu values exposed by Linux instead of validating every network device against the hardcoded 576 to 9200 range.

The values are collected with one rtnetlink link dump per getNetworkDevices
call, returned by luci-rpc, preserved in the shared network device model, and
used for form validation. Devices or kernels which do not expose the attributes
keep the existing fallback limits. The kernel maximum is also applied to the
IPv6 MTU field. The field is omitted on link-layer devices which cannot carry
IPv6's 1280-byte minimum.

The general MTU field retains the previous safe 576-byte floor when the kernel
reports a lower link-layer minimum.

The backend, model and form changes are split into their respective package
commits. The rpcd-mod-luci version is bumped so existing installations pull
the updated RPC module.

Testing

• git diff --check
• ESLint with Node.js 22 on the changed JavaScript files
• Cross-compiled rpcd-mod-luci for ramips/mt7620 (mipsel_24kc)

[openwrt-ai]

Commit checks

• 7d5612b "luci-mod-network: use device-specific MTU limits" — the subject scopes the change to luci-mod-network, but the commit also touches libs/rpcd-mod-luci/src/luci.c (new sysfs reads in the rpcd C plugin) and modules/luci-base/htdocs/luci-static/resources/network.js (new Device.getMinMTU()/getMaxMTU() API). CONTRIBUTING.md asks for a subject prefixed with the affected component, and this tree normally splits per-package changes into separate commits — here that would be three: one rpcd-mod-luci: (backend attributes + version bump), one luci-base: (model accessors), one luci-mod-network: (form validation). Splitting also makes the cross-repo/package dependency explicit, which matters because the frontend silently degrades to the old fallback range when the backend half is not installed.

---

Generated by Claude Code

[dormancygrace]

Addressed the review: split the backend, model and form changes into three package-scoped commits; bumped rpcd-mod-luci; synchronized the displayed and validated ranges; and applied the device-specific ceiling to IPv6 MTU. The branch was force-pushed and the PR description was updated.

[openwrt-ai]

Commit checks

• b50f6e0 "rpcd-mod-luci: expose device MTU limits" — the message says "Linux exposes the supported MTU range through min_mtu and max_mtu sysfs attributes", but the diff does not read sysfs: it opens a NETLINK_ROUTE socket and parses IFLA_MIN_MTU/IFLA_MAX_MTU from an RTM_GETLINK reply. There are no min_mtu/max_mtu files under /sys/class/net/<dev>/ (the kernel only exposes mtu there), which is presumably why the implementation moved to rtnetlink between revisions — but the commit message still describes the earlier sysfs approach. The PR body already says "read from rtnetlink"; the commit message should match.

The per-package split requested on the previous revision is done correctly — all three commit subjects match the files they touch.

---

Generated by Claude Code

[dormancygrace]

Fixed in the current head. Commit 135e2e1e37 now describes the actual implementation: one RTM_GETLINK dump, with no sysfs claim. The PR body already uses the same rtnetlink wording.

[openwrt-ai]

Reviewed 3 new commits (force-push over 49af795); no commit-message issues — the sysfs wording flagged last round is gone and each subject matches the files it touches.

The rtnetlink rework looks right: one RTM_GETLINK | NLM_F_DUMP per getNetworkDevices, the same nl_cb_alloc/nl_cb_set/nl_cb_err + pending shape as the existing rpc_luci_get_host_hints_nl(), and the limit list is freed on every path. Two nits inline.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 3 new commits (force-push over 3ae81b1). The only code change since the last revision is the sub-576 branch in tools/network.js, and it holds up: I exercised the new expression over the interesting (min_mtu, max_mtu) pairs — (68,1500)→range(576,1500), (128,300)→range(128,300), (0,300)→range(300,300), (400,300)→range(300,300), (null,null)→range(576,9200) — and every result is satisfiable with the kernel minimum preferred over the ceiling on low-MTU devices, which was the point. The three continuation-line re-indents in luci.c match the space-aligned style of the surrounding signatures. FormalityCheck is green on 8674732.

Commit checks

• 8674732 "luci-mod-network: use device-specific MTU limits" — the commit also touches libs/rpcd-mod-luci/src/luci.c (the three continuation-line re-indents at lines 705, 761 and 774), which is outside the luci-mod-network: subject scope and re-formats whitespace that 135e2e1 introduced earlier in the same series. Squashing those three hunks into 135e2e1 keeps each commit inside its own package — the split you did on the previous revision — and removes an introduce-then-fix pair from the series. 135e2e1 and 07836c5 match the files they touch.

---

Generated by Claude Code

[dormancygrace]

Good point. I moved the three rpcd-mod-luci continuation-line formatting changes into the first backend commit, so the final luci-mod-network commit now touches only tools/network.js.

The aggregate tree is byte-identical to the previously green 8674732947 head (git diff 8674732947..8ed21a4afc is empty); only commit ownership changed. Updated head: 8ed21a4afc.

[openwrt-ai]

Reviewed 3 new commits (force-push over 8674732); no new issues found.

I confirmed the rebase claim locally: git diff 8674732947..8ed21a4afc is empty, so the tree is unchanged and only commit ownership moved. The commit-check nit from the last round is resolved — f6eaaae now carries all of libs/rpcd-mod-luci/ (Makefile bump + luci.c, including the three continuation-line re-indents), ac41ffc only luci-base's network.js, and 8ed21a4 only luci-mod-network's tools/network.js. Each subject matches its files, and the introduce-then-fix pair is gone. All three FormalityCheck runs are green on 8ed21a4.

---

Generated by Claude Code