Accessing linkmeter variables from command line

[Steve_M]

Is there a way to access the linkmeter variables from command line? I was thinking of doing something like a cron job that would tweet out an update every hour with something like "$pn0: $pcurr0, $pn1: $pcurr1, $pn2: $pcurr2, $pn3: $pcurr3" but I'm not sure how to get those variables from the command line without having to make a parser for the output of lmclient

 

[Bryan Mayland]

If you only want to query specific items and not parse the entire LMCF JSON, you can use LMGT (linkmeter get):

lmclient LMGT,A,B,...

A = item to query
B = default if item is not set

root@OpenWrt:~# lmclient LMGT,pn0,Probe0,pn1,Probe1,pn2,Probe2,pnX,invalid
Probe 0
Probe 1
Probe 2
invalid

 

[Steve_M]

Thanks.

I can query pn[0-3] ok but I'm not getting anything back for pcurr[0-3] or sp

I can query some, but not a lot of the variables listed on the Alarm Script Recipes page

 

[Bryan Mayland]

Oh yesssssss the alarm's environment contains configuration (which is what LMGT gets) but is augmented with a snapshot of the current streaming data so it won't have those. Let me think about the best way to do that. It's been a pretty tough day today and my brain is just fried.

 

[Steve_M]

Ah. No worries. I'm in no rush.

 

[Bryan Mayland]

Try the latest snapshot, you should be able to get pcurr, alarms, current IP now!

root@OpenWrt:/usr/lib/lua/luci/lucid# lmclient LMGT,pcurr0,off,ip,unk,pall0,none
23
192.168.2.11
-40

 

[Steve_M]

Wow. Thanks for that. Much appreciated!

 

[Bryan Mayland]

Yeah I will admit it would be easier if I could let your script run in the context of the environment that the alarm scripts run, but that's a fork from inside the daemon which sets up the environment so it isn't easy to replicate. I'd be wary of allowing lmclient to just request execution of any executable you pass it on the basis that's a security researcher's wet dream, but I am open to other ideas.

The best thing to do would be to send the configuration table through the unix socket, recreate it in lmclient, then execute the script from a fork of the context of lmclient with the environment, but man that is a lot of work for something that probably won't get much use.

I am happy to see you using lmclient though!

 

[Steve_M]

That's understandable. I like lmclient because I've been a CLI / shell script guy for ages, though I'm running into some functional limitations of the default ash shell on OpenWRT. One of my goals for 2015 is to learn golang, so this might be a fun little thing to write, parsing the JSON output from /luci/lm/hmstatus.