Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR 189: warnings if device has no LED signal strength indicators #191

Closed
ae6xe opened this issue Dec 10, 2021 · 8 comments
Closed

PR 189: warnings if device has no LED signal strength indicators #191

ae6xe opened this issue Dec 10, 2021 · 8 comments
Assignees

Comments

@ae6xe
Copy link
Contributor

ae6xe commented Dec 10, 2021

The hap ac lite does not have signal strength indicator lights. (It has LEDs to show the switch ports are active.) This warning is showing through:
root@AE6XE-haplite-test:~# cat /tmp/manager.log
12/10 13:01:39: /usr/lib/lua/aredn/hardware.lua:139: attempt to index field 'rssilow' (a nil value)
[... repeats a lot]

@aanon4
Copy link
Contributor

aanon4 commented Dec 10, 2021

It means there's no led section defined in the /etc/board.json. Is there some fallback default I should use if this isn't available?

@ae6xe
Copy link
Contributor Author

ae6xe commented Dec 10, 2021

If no entry, we assume the LED does not exist on the device -- no action should be taken. Should the non-existing rssilow information in board.json be in error, then indeed the LED light would not be activated and a defect should/would be submitted -- correction would be made upstream to the image (generally by an openwrt PR).

@aanon4
Copy link
Contributor

aanon4 commented Dec 10, 2021

Could you post the board.json here for the offending device? Maybe I'm missing something, especially if this use to work.

@ae6xe
Copy link
Contributor Author

ae6xe commented Dec 10, 2021

board.zip

@aanon4
Copy link
Contributor

aanon4 commented Dec 10, 2021

So below there is an LED section, but which led should I be choosing for this device? I had been picking the 'rssilow' led in other devices, but this obviously doesn't have that entry.

In the original code there is a big switch statement for selecting the led, but we had hoped to use the board.json information instead. It looks like that might not be possible (in the short term anyway).

{
	"model": {
		"id": "rb-952ui-5ac2nd",
		"name": "MikroTik RouterBOARD RB952Ui-5ac2nD"
	},
	"led": {
		"user": {
			"name": "USER",
			"sysfs": "rb:green:user",
			"type": "timer",
			"trigger": "timer",
			"delayon": 1000,
			"delayoff": 1000
		},
		"port1": {
			"name": "port1",
			"sysfs": "rb:green:port1",
			"type": "netdev",
			"device": "eth0",
			"mode": "link tx rx"
		},
		"port2": {
			"name": "port2",
			"sysfs": "rb:green:port2",
			"trigger": "switch0",
			"type": "switch",
			"mode": "",
			"port_mask": "0x10",
			"speed_mask": ""
		},
		"port3": {
			"name": "port2",
			"sysfs": "rb:green:port3",
			"trigger": "switch0",
			"type": "switch",
			"mode": "",
			"port_mask": "0x08",
			"speed_mask": ""
		},
		"port4": {
			"name": "port3",
			"sysfs": "rb:green:port4",
			"trigger": "switch0",
			"type": "switch",
			"mode": "",
			"port_mask": "0x04",
			"speed_mask": ""
		},
		"port5": {
			"name": "port5",
			"sysfs": "rb:green:port5",
			"trigger": "switch0",
			"type": "switch",
			"mode": "",
			"port_mask": "0x02",
			"speed_mask": ""
		},
		"wlan": {
			"name": "WLAN",
			"sysfs": "rb:blue:wlan",
			"trigger": "phy0tpt"
		}
	},
	"network": {
		"wan": {
			"ifname": "eth0",
			"protocol": "dhcp"
		},
		"wifi": {
			"ifname": "wlan1",
			"protocol": "static"
		},
		"lan": {
			"ifname": "eth1.0",
			"protocol": "static"
		},
		"unused": {
			"ifname": "eth1.1",
			"protocol": "none"
		},
		"dtdlink": {
			"ifname": "eth1.2",
			"protocol": "none"
		}
	},
	"switch": {
		"switch0": {
			"enable": true,
			"reset": true,
			"ports": [
				{
					"num": 0,
					"device": "eth1",
					"need_tag": false,
					"want_untag": false
				},
				{
					"num": 4,
					"role": "lan",
					"index": 1
				},
				{
					"num": 3,
					"role": "lan",
					"index": 2
				},
				{
					"num": 2,
					"role": "lan",
					"index": 3
				},
				{
					"num": 1,
					"role": "unused"
				},
				{
					"num": 1,
					"role": "dtdlink"
				}
			],
			"roles": [
				{
					"role": "lan",
					"ports": "4 3 2 0t",
					"device": "eth1.0"
				},
				{
					"role": "unused",
					"ports": "1t 0t",
					"device": "eth1.1"
				},
				{
					"role": "dtdlink",
					"ports": "1t 0t",
					"device": "eth1.2"
				}
			],
			"ar8xxx_mib_type": 0,
			"ar8xxx_mib_poll_interval": 500
		}
	},
	"gpioswitch": {
		"usb_power_switch": {
			"name": "USB Power Switch",
			"pin": 45,
			"default": 1
		},
		"poe_passthrough": {
			"name": "PoE Passthrough",
			"pin": 14,
			"default": 0
		}
	}
}

@ae6xe
Copy link
Contributor Author

ae6xe commented Dec 11, 2021

The 5 LEDs on top show ethernet traffic activity on the 5 ports. The 2 LEDs on the front: 1 is power-on, the other is labeled "USR" on the front panel, and shows up as "rb:green:user" and "USER". I believe this LED is already used by openwrt and lights up when linux is booted up. There's isn't another LED to use for mesh link status. The prior code did not correctly find anything ether -- looks like it defaulted and looked for "*link1", which doesn't exist on this device. I vote -- take no action for this device, no LED available for this purpose.

@aanon4
Copy link
Contributor

aanon4 commented Dec 11, 2021

I'm find with no light on this device, although I'm going to tidy up the led detection code a little so it return nil rather than failing if there are leds, but not the "correct" one.

@aanon4
Copy link
Contributor

aanon4 commented Dec 11, 2021

Improved error handling here - 6e32045

If you're happy with the resolution, please close this - thanks.

@dman776 dman776 closed this as completed Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants