disable debug logging

[jhpoelen]

from https://sudoroom.org/pipermail/mesh/2017-October/002600.html reported by D.

Are all PON nodes pushing logs to a remote location, or is t just me?

I SSH to my PON node and while checking for current connections I see this
established connection "100.64.0.10:514 (Syslog Server?)?
Been refreshing for about 20+ minutes and the connection seems constant.

Can someone please explain this?

[wwwhtml]

My node is fixed.

The node's configuration file that handles this syslog connection is at:
/etc/config/system.

I suggest all nodes be patched.

[jhpoelen]

See related projects https://github.com/sudomesh/sudowrt-firmware and https://github.com/sudomesh/makenode .

[paidforby]

@wwwhtml and @jhpoelen i found the offending file in makenode.

To reproduce:

1. ssh into a newly flashed/configured home node
2. run netstat
3. observe output,

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
udp        0      0 10.0.0.10:50737         104.236.181.226:8942    ESTABLISHED 
udp        0      0 10.0.0.10:46660         omnicommons.org:8942    ESTABLISHED 
udp     2240      0 10.0.0.10:35413         unassigned.psychz.net:8942 ESTABLISHED 
udp        0      0 10.0.0.10:ntp           test.diarizer.com:ntp   ESTABLISHED 
udp        0      0 10.0.0.10:44927         104.236.181.226:8943    ESTABLISHED 
udp        0      0 10.0.0.10:33943         sudoroom.org:8942       ESTABLISHED 
udp        0      0 <hostname>.peoplesopen.net:40870 100.64.0.10:syslog      ESTABLISHED 
udp        0      0 10.0.0.10:56231         142-254-26-9.dsl.static.fusionbroadband.com:8942 ESTABLISHED 
udp        0      0 10.0.0.10:35261         107.170.219.5:8942      ESTABLISHED 
udp        0      0 10.0.0.10:43967         unassigned.psychz.net:8943 ESTABLISHED 

Notice the line that reads,

udp        0      0 <hostname>.peoplesopen.net:40870 100.64.0.10:syslog      ESTABLISHED 

Expected results:

After removing the lines regarding logging in the file, /etc/config/system, you should no long see the connection to syslog server when you run netstat

[paidforby]

Can confirm that latest commit to makenode fixes this issue on newly configured home nodes.

[jhpoelen]

@paidforby nice!

[gobengo]

@jhpoelen This is tagged with helpwanted. What kind is needed, given @paidforby last comment about makenode?

@paidforby do you know off hand if latest firmware (including your epic noconfig improvements) also produces home nodes that don't debug log?

[paidforby]

@gobengo so this bug was originally introduced by makenode via the /etc/config/system file. Apparently, I confirmed some months ago that makenode v0.0.1 no longer triggered this bug. I'm assuming I only checked makenode on an N600, so someone should also check an N750, if you can find one.

Of course, this was never an issue directly with the firmware repo, but I introduced that possibility with the noconfig additions, so you are right to ask about that. However, it is easy enough to check, you can see that files/etc/config/system does not reintroduce this bug. Additionally, there is no files/opt/mesh/templates/etc/config/system which would overwrite that first file after autoconfiging.

Extender nodes also seme free of this bug by checking files_extender-node

It should also be noted that new makenode does not introduce this either, since that is mostly just an offline method for triggering autoconf,.

For future reference, this bug was triggered by the following lines in /etc/config/system,

option log_proto udp
option log_port 514
option log_prefix <%= host_name %>

I believe the conversation for leaving this opening had something to do with visibility for node patching, but the issue as a whole seems pretty well buttoned up. Though the N750 and TP-Link routers still need to be tested. My feeling is that as soon as we have N750s, or are able to consistently flash TP-Link routers, then we can reopen this issuie, if necessary. If anyone disagrees, feel free to reopen immediately.

@gobengo thanks for pointing out that this was still open, despite being more or less resolved.

[gobengo]

Thanks for the detailed recap and lessons learned @paidforby .

[bennlich]

For future reference, this bug was triggered by the following lines in /etc/config/system,

option log_proto udp
option log_port 514
option log_prefix <%= host_name %>

I believe

option log_ip <%= log_ip %>

was also important too. Maybe the most important. There's some documentation about all these settings here: https://wiki.openwrt.org/doc/uci/system.

--

@gobengo @paidforby I think this issue was left open because we have yet to write a patch that removes this config from existing nodes in the wild.

I was hoping to write this patch, but I got stuck because the log_prefix <%= host_name %> line varies from node to node, and I couldn't figure out how to use the patch tool to account for this (probably need to use something other than the patch tool). This was also around the time we were having conversations about using a package server for patches. Eventually I got distracted by other things and forgot I was working on this :-/

I opened a new issue here because there are still nodes in the wild that are calling home to log, which is a bug.