lime-system: detect radios on any bus in wireless.scandevices() - #18
Open
Pablomonte wants to merge 2 commits into
Open
lime-system: detect radios on any bus in wireless.scandevices()#18Pablomonte wants to merge 2 commits into
Pablomonte wants to merge 2 commits into
Conversation
scandevices() skips wifi-devices whose hardware is missing by globbing /sys/devices/<uci path>/ieee80211/phy*, but the path netifd stores in uci is relative to a bus prefix that varies per target. On ramips/mt7621 -- the SoC of the LibreRouter R2 -- the PCIe controller is a platform device and uci holds '1e140000.pcie/pci0000:00/...' while sysfs exposes /sys/devices/platform/1e140000.pcie/..., so the glob never matched and every ath9k radio of a LibreRouter v1 card was reported as 'hardware not found'. lime-config then generated no wifi-iface at all and the three radios stayed disabled. Resolve the device path of each phy under /sys/class/ieee80211 with realpath(3) and match the uci path against it instead of guessing the prefix. Anchoring the match on '<path>/ieee80211/' keeps a parent PCIe bridge from matching its child radio, and comparing literally rather than as a Lua pattern keeps the dots and colons of PCI paths from acting as wildcards. This also handles the '+N' suffix netifd appends when several phys share one device (e.g. mt7915 DBDC), which the old glob missed too. The check stays a strict superset of the previous one: sysfs /sys/devices is the canonical tree with no internal symlinks, so realpath is the identity on an already real path and no radio the old glob accepted can be lost. Stale radios are still rejected, which is what keeps firstbootwizard from asking for a phy that does not exist and dying in get_phy_mac(). Tested on a LibreRouter R2 (LibreRouterOs 2025.10, kernel 6.6.121) with three ath9k radios: the old glob matched none of the three uci paths, the new check resolves all of them to phy0/phy1/phy2, and a stale radio path is still reported as missing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The #librerouter test feeds lime-config the wireless config OpenWrt generates on a LibreRouter v1, whose three wifi-devices carry real sysfs paths (platform/qca955x_wmac and two PCI ones). Those paths do not exist inside the test container, so scandevices() correctly reports the radios as missing hardware, no mesh interface is generated and the assertion on lm_net_wlan1_mesh_babeld_dev fails. This failure predates the previous commit: it appears on a clean checkout as soon as scandevices() started filtering absent hardware. Fake the three phy entries the fixture expects so the test exercises the device config it is meant to cover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
scandevices()filters out radios whose hardware is missing by globbing/sys/devices/<uci path>/ieee80211/phy*, but the path netifd stores in uci is relative to abus prefix that varies per target. On ramips/mt7621 (LibreRouter R2) the PCIe controller is a
platform device: uci holds
1e140000.pcie/pci0000:00/...while sysfs exposes/sys/devices/platform/1e140000.pcie/.... The glob never matched, so the three ath9k radios ofa LibreRouter v1 card were all reported as hardware not found,
lime-configgenerated nowifi-ifaceand the radios stayed disabled.Instead of guessing the prefix, resolve each phy under
/sys/class/ieee80211withrealpath(3)and match the uci path against it:
<path>/ieee80211/keeps a parent PCIe bridge from matching its child radio;+Nsuffix netifd appends when several phys share one device (mt7915 DBDC) is handled too — the old glob missed it as well.The check stays a strict superset of the previous one:
/sys/devicesis the canonical sysfstree with no internal symlinks, so
realpathis the identity on an already real path and noradio the old glob accepted can be lost. Stale radios are still rejected — that is what keeps
firstbootwizardfrom asking for a phy that does not exist and dying inget_phy_mac().Tested on a LibreRouter R2 (LibreRouterOS 2025.10, kernel 6.6.121) with three ath9k radios: the
old glob matched none of the three uci paths, the new check resolves all of them to
phy0/phy1/phy2, and a stale radio path is still reported as missing.
Tests
The second commit fixes
tests/test_lime_config_device.lua(#librerouter), which is alreadyred on
final-releasefor the same root cause: the fixture's sysfs paths do not exist in thetest container, so all three radios get filtered out and no mesh interface is generated.
Replaces #17, which was opened from the wrong head branch (
Pablomonte:master, carrying twounrelated lime-app commits) and against
masterinstead offinal-release.