public PON, private PON & home network route through same IP

[elleko]

All 3 SSIDs in users homes (public Peoplesopen Network, private PON, and home network form user's ISP) are routing through the same IP address. IP of Users' home networks are directly exposed to be used by anyone connected through public PON.
Node at Sudo Room and at least 3 other nodes report this issue, possibly network wide.
First observed 08/04/2017 on 2 independent nodes.

To Reproduce:

1. At a node, run traceroute or (Google what is my ip?) on home wifi SSID, note the IP information.
2. Run traceroute on private PON SSID; note info.
3. Run traceroute on public PON SSID; note info.

Result:
All 3 SSIDs route through the same IP address.

Screenshots from traceroute on 2 nodes attached.


[elleko]

[paidforby]

Fixed on live nodes by @Juul via ssh. Addressed permanently in firmware in this commit, yet to be tested.

[paidforby]

Per a conversation at sudoroom, this issue cannot (should not?) be fixed by a firmware update. The meshrouting config is actually done by makenode. Bug can be fixed by using any commit of makenode after this one from Oct 26, 2017. So any node flashed and configed after that date should have the correct firewall rules assuming you cloned/pulled makenode from HEAD (generally a safe assumption?). @Juul pushed this update to as many nodes as possible circa Sept 2017. Any older nodes that failed to get the patch, we should assume need to be reflashed. I'm going to close this issue, please reopen if it is directly related #8.

However, this bug does bring to mind other issues:

1. How can reliably and securely push patches/updates to nodes or otherwise encourage node operators to reflash/config their nodes?
2. Can we roll makenode configs into firmware so changes aren't split across two repos?
3. Maybe we could add a bug log to the bugs repo readme? Then this repo would get pushed to the top of the sudomesh github, otherwise I completely forget it exists (maybe this is a personal problem).

For remote patching, updating/replacing makenode, or improving bug control/visibility we can open new issues.

P.S. sorry for not updating this bug sooner, I forgot about it.

[jhpoelen]

@paidforby thanks for the update, I suggest we keep this bug open until after #8 is resolved and active nodes are patched by network node operators @Juul @max-b and @papazoga .

[paidforby]

I feel the bug originally stated by this issue is unrelated to the current exit node outage. If anything, the current outage proves that this problem has been fixed since no one is complaining about their node using their home router's IP address. This is indicative that active nodes were patched as concerns this issue. Broader questions related to node patching (how it's done, when it's done, who does it) seem to go outside the scope of the original issue. My ultimate point is: if this issue had been closed in October 2017 (as it should have been), it would not have been reopened because of #8 . Regardless, do as you see fit.

[jhpoelen]

Thanks for elaborating.

First, I don't think most node owners realize that peoplesopen.net expose their public ips. If you mean to say that the outage shows that peoplesopen.net SSIDs do not provide a route to the "big" internet, then I'd argue that most people don't bother complaining.

As far as this issue goes - I think we are discussing semantics - I consider a bug to be resolved once a fix is in, is tested and deployed. As long as we keep a visible public to indicate that node need to be patched sooner rather than later. I've added a label to the bug called "node patch pending". The dependency with #8 is introduced, because nodes need to be reachable through the mesh in order to be patched. Perhaps something to discuss on Tuesday.