Vectoring on Lantiq VRX200 / VR9 - missing callback for sending error samples

@janh . Thank You for your work . I took the liberty of creating pull request to stable branch .

My line is not vectoring enabled so feel free to create feedback in this pull

1 Like

did i get it right that in order to use the patch, i need to install the developement snapshot? or do i need to apply the patch and compile openwrt myself?

Yes, this is correct. The patches are included in snapshot images, but not in any stable release.

@janh, being at OpenWrt SNAPSHOT r19597-65258f5d60 I was wondering how to get the DSL graphs in. Normally I've no issue in getting any graphs in but the DSL graphs seem to behave difficult. Any clue or direction that would help?

There aren't any DSL graphs in a standard OpenWrt installation, so which graphs do you mean?

The ones that appear higher up in this topic, which show DSL SNR, etc.


Beautiful work - thanks!

I believe that the location of the ACL JSON in the readme needs updating from /usr/share/rpcd/acl.d/collectd-exec-lantiqdsl.json to /usr/share/acl.d/collectd-exec-lantiqdsl.json as it's correct in the repo. On my HH5a, placing the JSON within rpcd had no effect on the ubus permissions after a reboot and the script ran but ultimately didn't collect any data and the DSL graph page never appeared.

Anyway, all good now. This is definitely worthy of packaging!


You are absolutely correct.I have no idea where I got the additional "/rpcd" from. I fixed it, thanks for the correction!

I don't see how to properly package a set of scripts that runs on top of another package. I could try though. But honestly, in the end it's three files with an optional fourth.

1 Like

IMHO the nicest would be to simply package these as part of at least xrx200 builds (or any lantiq builds with DSL functionality), they appear small enough not matter much for size and are clearly something quite useful...

Since neither collectd nor collectd-mod-exec are in the default packages (of course they aren't), I don't see why they would (or even should) include files building on those packages.

It's always an option to include the three (four) files when building one's own custom image (which is what I do using the ImageBuilder).

The modified rrdtool.js, however, could maybe go into luci-app-statistics. Interesting sidenote: One of the things I modified is the ability to (un)set the line width. The current rrdtool.js already has a "width" parameter for setting the line width, but it's not picked up from the configuration file. Someone must have forgotten.

Fair point.

That's what I did with my last build, dump the files/folders into ${openwrt_build_root}/files, but that is not helping consumers of normal stable builds that might naively expect something like you nice visualization tools to be there by default, no?

+1 if that means one less file for your github project to carry even better :wink:

Of course not, but that expectation will never be met. Even if my files were included the user would still have to install luci-app-statistics and collectd-mod-exec and configure the latter. At that point they would have to look up what to configure anyway, and from there it's just a minor inconvenience having to install the files themselves. I don't think there's a win to be had here.

I accept your position, just for completeness, luci-app-statistics and collectd-mod-exec can be easily installed from the GUI or CLI from the default repository, your scripts however require a bit more involvement/action from the potential users and can not be detected from looking at the packet sources :wink: .

I see your point, but that's not going to change. For a convenient "install package" experience, my package would have to go into the default repository, and I don't see that happening. I'm not trying to be difficult or save myself from work here: A major part of my scripts is the exec.js "configuration" for rrdtool/luci-app-statistics, and we don't have exclusive rights to that file.

Edit: It may be worth looking into luci-app-statistics, maybe it's possible to pull not only a singular exec.js, but multiple exec-<execplugin>.js if available. As is, this is a general problem: If you have multiple exec scripts you still have only one exec.js that has to visualize all data from all exec plugins. I believe it's only due to the fact that almost noone ever uses multiple exec scripts that this hasn't lead to problems before.

For this to be done in an upstreamable way, one would have to create a collectd plugin. And while that's probably not too difficult, I'm not up to that task, my language proficiency in C/C++ is entirely passive.

1 Like