[Mesh] What's up with this? You may want to Check your node. The one I have has this constant connection to a Server log ("100.64.0.10:514")?

[Jehan Tremback]

Are we in control of the server with this IP? If so, we should turn it off
and hold onto the IP to prevent future logging without having to update
every peoples open node out there. If someone else is in control of the
server, we need to find out who they are and get it from them.

On Wed, Oct 4, 2017 at 5:38 AM, Jorrit Poelen <jhpoelen at xs4all.nl> wrote:

> Hi Daniel -
>
> Thanks for sharing this and asking for opinions.
>
> Personally, I am fan of keeping as little identifiable information around
> as possible. The mesh prototol itself already provides plenty of
> information about other nodes, so from where I am standing, I don't see the
> immediate need for centralized logging beyond keeping a temporary log of
> mesh routing tables.
>
> Also, I'd say that the great thing (and bad thing) about centralized
> logging servers is that they can be easily turned off.
>
> Hoping I can join a lively discussion on this for the next meeting.
>
> thx,
> -jorrit
>
> On Tue, 2017-10-03 at 23:49 -0700, danarauz at gmail.com wrote:
>
> Update:
>
> I also notified about this finding to folks that are part of the mesh
> Signal Messaging group, and so far the person replying says that it may be
> a centralized log Server. A link ( https://github.com/sudomesh/
> sudowrt-firmware/issues/68 ) was also provided, about an issue in github
> that talks about the implementation of this Syslog Server.
>
> After reading the issue on github, I checked on the /var/log/messages file.
> This log file collects all the HostNames, IP address, and MAC address of
> all connecting devices (computers, phones, iPads, AppleTVs, etc) to the
> Mesh and Private networks.
>
> Even though I understand the need for logs for troubleshooting purposes, I
> would like to know others folks thoughts about this collection.
>
> Are you okay with this?
> How critical is to have these log files?
> Is possible for Peoples Open Network to be part of the "No Logs, No
> Masters" idea?
>
> With the absolute intention of making the PON stronger and safer,
>
> Daniel
>
>
>
> On Tue, Oct 3, 2017 at 9:04 PM, danarauz at gmail.com <danarauz at gmail.com>
> wrote:
>
> screenshot attached.
>
> On Tue, Oct 3, 2017 at 8:59 PM, danarauz at gmail.com <danarauz at gmail.com>
> wrote:
>
> What's up with this?  You may want to Check your node. The one I have has
> this constant connection to a Server log ("100.64.0.10:514")?
>
> 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?
>
> Daniel
>
>
>
>
>
> --
> Daniel
>
> Signal: 415.336.9143 <https://whispersystems.org/>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
> Help open a people-powered common space in Oakland, California!
> https://omnicommons.org/donate
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
>
>
>
>
>
>
> --
> Daniel
>
> Signal: 415.336.9143 <https://whispersystems.org/>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
> Help open a people-powered common space in Oakland, California!
> https://omnicommons.org/donate
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
>
>
> _______________________________________________
> mesh mailing listmesh at lists.sudoroom.orghttps://sudoroom.org/lists/listinfo/mesh
>
>
> _______________________________________________
> mesh mailing list
> mesh at lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/mesh
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh/attachments/20171004/2dc6dbdc/attachment.html>