RFC: Default settings for first-boot

[pmelange]

With the changes in 21.02 we should rewrite how networking is set up in the defaults packages (see #182). I propose the following for the first-boot scenario. If there are any other ideas for the first-boot settings, please contribute to this issue. Note: this is a discussion about the settings before the wizard/luci is started.

• Currently, the default settings for dnsmasq have list dhcp_option '3' on the "lan" interface which causes any attached clients to not have a default route. In the firewall config, the "lan" interface is not in any firewall zone preventing forwarding. The combination of these causes any attached client not to be able to reach the internet. The reason for this is to force the user to configure the router completely before it's put into service. The problem with this setup is that the map feature (to choose the coordinates) does not work. I propose that we set it up so that
  1. list dhcp_option '3' is not set (let the client get a default route)
  2. a temporary "setup" firewall zone is created which enables forwarding from the "lan" interface, but only to those domains needed for the map to work. I believe this can be accomplished with ipset (https://openwrt.org/docs/guide-user/firewall/fw3_configurations/dns_ipset but instead of allow everything and block specific, we should block everything and allow specific) on the hostnames "*.opensteetmap.org" and "cdnjs.cloudflare.com". This needs some testing.
• Currently, DNS servers are not active in the first-boot setup. This is done, per default, via the option peerdns '0' option in the "wan" interface. This prevents both the router and any attached client from being able to resolve hostnames. While we prefer to use DNS servers which are privacy-friendly, for first-boot I would argue that the DNS server provided over the "wan" interface is totally usable. I could also imagine hard-coding a privacy-friendly DNS server into the config, but that would just add some maintenance issues.
• Currently, wireless is disabled per default. I propose setting up an SSID based on the MAC of the router. Perhaps something like "freifunk-config-f81a675aa24c". Such an SSID would be unique for each router, making it still possible to have workshops/install parties/hackathons without interfering with each other. One should be able to look at the label on the router to determine which SSID to connect to (when multiple "freifunk-config-*" SSID's are available).

[kls0e]

many thanks for wrapping your head around this.

  2. a temporary "setup" firewall zone is created which enables forwarding from the "lan" interface, but only to those domains needed for the map to work.  I believe this can be accomplished with ipset (https://openwrt.org/docs/guide-user/firewall/fw3_configurations/dns_ipset but instead of allow everything and block specific, we should block everything and allow specific) on the hostnames "*.opensteetmap.org" and "cdnjs.cloudflare.com".  This needs some testing.

is there any other approach? does utilizing namespaces help? hard-coding these hostnames might evoke future issues as we would be dependent on the current state of hostname topology involved which of course is not set in stone.

* Currently, DNS servers are not active in the first-boot setup.  This is done, per default, via the `option peerdns '0'` option in the "wan" interface.  This prevents both the router and any attached client from being able to resolve hostnames.  While we prefer to use DNS servers which are privacy-friendly, for first-boot I would argue that the DNS server provided over the "wan" interface is totally usable.  I could also imagine hard-coding a privacy-friendly DNS server into the config, but that would just add some maintenance issues.

+1 for WAN DNS

* Currently, wireless is disabled per default.  I propose setting up an SSID based on the MAC of the router.  Perhaps something like "freifunk-config-f81a675aa24c".  Such an SSID would be unique for each router, making it still possible to have workshops/install parties/hackathons without interfering with each other.  One should be able to look at the label on the router to determine which SSID to connect to (when multiple "freifunk-config-*" SSID's are available).

* Currently, wireless is disabled per default.  I propose setting up an SSID based on the MAC of the router.  Perhaps something like "freifunk-config-f81a675aa24c".  Such an SSID would be unique for each router, making it still possible to have workshops/install parties/hackathons without interfering with each other.  One should be able to look at the label on the router to determine which SSID to connect to (when multiple "freifunk-config-*" SSID's are available).

+1 for SSID, these 28 chars fit into 32 chars max ssid length.

[Noki]

While this would be a work around for nodes attached to an internet connection during setup, it would not work for nodes setups without an internet connection.

It would be a good idea to remove the map-feature from the wizard in case the required hosts are unreachable. Instead of the map a notice should be shown that tells the user that he can manually enter the coordinates or configure them later using a map once the node is setup and has an internet connection.

Another way would be to ask the user for permission to automatically determine the position. The position from the the device accessing the wizard could be used (https://developer.mozilla.org/de/docs/Web/API/Geolocation/getCurrentPosition) which would work if you setup the node where it is installed at the end (Examplecode: https://codepen.io/ambiweb/pen/PoprmMX). Another way would be to ask for permission to use the Mozilla Location Service (https://location.services.mozilla.com/) and then use known wifi networks to periodically determine the location of a node.

I love the idea with the config SSID this makes it a lot easier to configure nodes.

[Akira25]

Sounds really good to me. For 1.ii) I'd like to have *.freifunk.net added too. Thus one can check the wiki/forum/tutorial too.

[pmelange]

While this would be a work around for nodes attached to an internet connection during setup, it would not work for nodes setups without an internet connection.

yes

It would be a good idea to remove the map-feature from the wizard in case the required hosts are unreachable. Instead of the map a notice should be shown that tells the user that he can manually enter the coordinates or configure them later using a map once the node is setup and has an internet connection.

Currently, as clients have no access to internet even with WAN attached, the map just doesn't show up. I guess that it would be the same "look and feel" as it is now. Simply no map.

Another way would be to ask the user for permission to automatically determine the position. The position from the the device accessing the wizard could be used (https://developer.mozilla.org/de/docs/Web/API/Geolocation/getCurrentPosition) which would work if you setup the node where it is installed at the end (Examplecode: https://codepen.io/ambiweb/pen/PoprmMX). Another way would be to ask for permission to use the Mozilla Location Service (https://location.services.mozilla.com/) and then use known wifi networks to periodically determine the location of a node.

I don't really like this idea. It's not always going to be the case that someone sets up a router at the same place where they want to deploy it (for example, at a friend's place, freifunk meeting, workshop, install party).

I love the idea with the config SSID this makes it a lot easier to configure nodes.

[pmelange]

Sounds really good to me. For 1.ii) I'd like to have *.freifunk.net added too. Thus one can check the wiki/forum/tutorial too.

Great idea.

[pmelange]

At a recent freifunk meeting we discussed the possibilities a little bit more and came up with the following idea.

• Upon firstboot, enable a tunnel (tunneldigger) so any traffic through a non-configured router is not sent directly over the user's local internet connection.
  • This is possible, but would be tied to some hard coded tunnel connection and would not be based off of any community settings.
  • Optional: It should be possible to create a separate "setup server" which accepts tunneldigger clients but limits the traffic to just the pages needed for clicking on the map and accessing the *.freifunk.net domains.
    • Benefit: creating a set of firewall rules would only have to be done and maintained on the server.
    • Benefit: The firewall rules on the router would be simpler to implement. Also extra packages, like ipset, would not be needed

Please provide some feedback

[pmelange]

I could use some support testing an idea. I have tried it on a few routers and so far it's worked overall.

The test is this:
On one router, set the 5ghz radio to VHT40 (do it with vi on the console otherwise a nasty bug will show up).
On the other router, leave the 5ghz radio to HT20.
Make sure they mesh
Turn off 2ghz mesh
Make sure they mesh
do a speed test between the routers.

Now set the second router also to VHT40 and do the tests again.

It would be cool to test this also on routers which do not support VHT40. Try setting it to VHT40 and see if it still works. Repeat the tests.