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

New sysinfo json changes #405

Merged
merged 5 commits into from Apr 30, 2019

Conversation

@r1de
Copy link
Contributor

commented Apr 17, 2019

Add additional info about the RF link(s) status to sysinfo.json

Dependent on #389 and #391
Replaces PR #387

r1de added 3 commits Mar 28, 2019
sysinfo.json additions
lua library additions

Dependent on #389 and #391
Replaces #387
additional check for nil needed
tested on a node with several very marginal RF links (IP, no host name) and it is working, so far.
also removed the decimal point on the n/lq values, we didn't need 10 places of accuracy. :)
@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Note:
Check the display of links that are dtd, tun, etc.
Seems to only show RF links now. (which is just fine)
I think the intended behavior was different though.

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

the olsr.getCurrentNeighbors() function is returning linkType properly....

`

aredn_olsr=require("aredn.olsr")
ho=aredn_olsr.getCurrentNeighbors()
print(ho)
table: 0x83be80
require("aredn.utils")
print_r(ho)
table: 0x83be80 {
[10.114.181.21] => table: 0x83be80 {
[neighborLinkQuality] => 1
[linkQuality] => 1
[hostname] => "K5DLQ-UNSM2-101.local.mesh"
[olsrInterface] => "wlan1"
[linkType] => "RF"
}
[10.115.181.21] => table: 0x83be80 {
[neighborLinkQuality] => 1
[linkQuality] => 1
[hostname] => "K5DLQ-UNSM2-101.local.mesh"
[olsrInterface] => "eth1.2"
[linkType] => "DTD"
}
}
`

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Ok, I am using the function wrong then or something. I'll try to look tonight.

Thx

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

I see where my confusion was coming from now.
The neighborLinkInfo() function in info.lua is only looking for the RF neighbors.
I will have to change it to show all of the neighbors and add in the additional info for the RF neighbors.

So, @dman776 and @ae6xe what if we were to use this neighbor link info in sysinfo.json file to replace the need for the "dot_draw" OLSR plug-in?
Since the same info (and more) would now be available via the sysinfo.json file, the dot_draw plugin would be redundant.
That would rid us of the plug-in itself and the need for xinetd, since, IIRC, xinetd is only there to redirect port 2004 to localhost:2003.

My map uses port 2004 to get quite a bit of info, I can change that, but I am not sure if any other people are using the info on port 2004 for anything, perhaps we could make a sticky on the forums asking if anyone is using the port and go from there?

Just thinking out loud here.
I'll fix this PR so it works "correctly" regardless...

@r1de r1de closed this Apr 18, 2019

@r1de r1de reopened this Apr 18, 2019

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

misclick... sorry. :)

changed neighborLinkInfo() function in aredn.info to show *all* links…
…, not just RF.

Adds additional info for each RF link (tx/rx_rate, noise, signal)
@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

Tested on 3 different nodes, 1 with many RF links, 1 with many DtD links, and 1 that is only PtP.
Not tested with tunnels yet.

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

isn't this information already in the olsr.getCurrentNeighbors() function? Why not just call it instead of creating another function in info.lua?

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

Not all of the info is in there, but most of it. The additional RF link info gets added in by my function.
But you know, I was asking myself this same thing earlier, and I am not sure. 😄
I think part of it was having to add the additional info in for the "RF" linkType and another part is just a personal preference of having the nodes name as the "index" instead of the IP.

I'll look it over again, I probably can be more efficient.

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

let's combine if we can. Since it's json it shouldnt break anything by adding new data to the structure.

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

also, if your code adds additional processing load (ie. file i/o, etc.), you can add an argument to the function to enable/disable your additional data. just a thought

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

Good idea(s).
I'll look once I get out of puppy chasing mode... "Nooooo, don't chew on that..." 😄

Removed redundant function.
Removed functions no longer needed.
Reworked getCurrentNeighbor function to add in the additional RF link info if requested.
@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2019

This is better I think.

@dman776
Copy link
Contributor

left a comment

when i copy these changed files to a node, sysinfo.json fails with:
root@K5DLQ-MRB-HAPACLITE:/www/cgi-bin# ./sysinfo.json
/usr/bin/lua: /usr/lib/lua/aredn/info.lua:69: attempt to index upvalue 'aredn_uci' (a boolean value)
stack traceback:
/usr/lib/lua/aredn/info.lua:69: in function 'getNodeName'
./sysinfo.json:62: in main chunk
[C]: ?
root@K5DLQ-MRB-HAPACLITE:/www/cgi-bin#

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 24, 2019

Recopied scripts to a node I was using for testing...
If I run the new scripts from the command line like that, I get:

root@WD6EBY-VC-SulphurMtn-to-Oxnard-5G:/www/cgi-bin# ./sysinfo.json 
/usr/bin/lua: ./sysinfo.json:151: attempt to index a nil value
stack traceback:
	./sysinfo.json:151: in main chunk
	[C]: ?

The "QUERY_STRING" is nil
Running from httpd works fine though.

I'm not even sure how you got that error.

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

@dman776 I still cannot recreate your error.
I modified my script to continue if the "QUERY_STRING" is nil, the script runs fine now and outputs as it should, but I still do not get that error when I run sysinfo.json from the command line.
Are you sure the firmware on your K5DLQ-MRB-HAPACLITE system has some of the newer updates needed? (#389 and #391)

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

just to be sure, do a build and load it to test.

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

roger roger

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

to ensure a clean build....

docker run --rm -it --name builder arednmesh/builder

then, inside the container:

git pull
git fetch origin pull/405/head:pr-405
git checkout pr-405
make

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

I still can't recreate it.

root@kg6wxc-test:/www/cgi-bin# cat /etc/mesh-release 
wxc-pr-405-e9c06dc
root@kg6wxc-test:/www/cgi-bin# ./sysinfo.json
/usr/bin/lua: ./sysinfo.json:151: attempt to index a nil value
stack traceback:
	./sysinfo.json:151: in main chunk
	[C]: ?

If I change the script on the node so it continues even if QUERY_STRING is nil, it works just fine and there are no other errors.

root@kg6wxc-test:/www/cgi-bin# ./sysinfo.json
Content-type: application/json
Cache-Control: no-store
Access-Control-Allow-Origin: *


{
   "lon": "-120.360363",
   "sysinfo": {
     "uptime": "0 days, 0:04:49",
     "loads": [
       0.46999999999999997,
       0.40000000000000002,
       0.19
     ]
   }, ...
@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

@dman776
Copy link
Contributor

left a comment

tested ok with a local build.

@dman776 dman776 merged commit 0300874 into aredn:develop Apr 30, 2019

@r1de

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

Should I also add in the changes to make it run from the command line when there is no "QUERY_STRING"?
Do we need it to run from the command line?
I guess it could be handy for something... :)

@dman776

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.