libremesh/libremesh.github.io

LibreMesh web site using Jekyll

libremesh.github.io's Issues

Portuguese Brasil translation

There is some content translated in portuguese from Brasil (PT/BR) which could be reviewed and included in multi-lingual LibreMesh website/how_it_works:
https://vedetas.org/wp-content/uploads/2017/06/libremesh_como_funciona_PT_BR.pdf
Does anyone know portuguese enough?

libremesh.org inaccessible over advertised IPv6

$ curl -v6 libremesh.org
* Rebuilt URL to: libremesh.org/
*   Trying 2a00:1508:1:f001::106...
* TCP_NODELAY set
* connect to 2a00:1508:1:f001::106 port 80 failed: Connection timed out
* Failed to connect to libremesh.org port 80: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to libremesh.org port 80: Connection timed out

Broken links

A quick check with LinkChecker revealed the following errors (I propose this as an easy first issue for new contributors):

URL https://snapshots.libremesh.org/snapshots
Name development snapshots
Parent URL https://libremesh.org/getit.html, line 100, col 117
Result Error: 404 Not Found

URL mailto:[email protected]
Name [email protected]
Parent URL https://libremesh.org/docs/en_quick_starting_guide.html, line 417, col 112
Warning [mail-no-mx-host] No MX mail host for thisnode.info found.

URL quick_starting_guide.html
Name Quick Starting Guide
Parent URL https://libremesh.org/docs/en_troubleshooting.html, line 390, col 201
Result Error: 404 Not Found

Add link to Freenode webchat in Communication page

A link like this could help new users to enter our IRC channel.

https://webchat.freenode.net/?channels=libremesh

Add Spanish mailing list to site

This is the link: https://lists.libremesh.org/mailman/listinfo/lime-es

Python2 distutils missing from compilation instructions

On Ubuntu 20.04 @jkimmel reported:

make[3]: Entering directory '/home/ilario/openwrt/tools/scons'
./files/pywrap.sh /home/ilario/openwrt/build_dir/host/scons-3.0.5/setup.py install --prefix=/home/ilario/openwrt/staging_dir/host
Traceback (most recent call last):
  File "/home/ilario/openwrt/build_dir/host/scons-3.0.5/setup.py", line 26, in <module>
    import distutils.command.build_scripts

this means we need to add libpython2-stdlib to the compilation dependencies.
@jkimmel can you confirm and prepare the pull request?

Merge italian guide

I wrote a guide in Italian here: http://wiki.ninux.org/Libre-Mesh but I never took the time for merging its contents in Italian in the LibreMesh website.
The contents will need to be adapted to LibreMesh website and what's missing in English version should be translated back to English documentation.

Please setup HTTPS on http://downloads.libremesh.org/

That subdomain contains firmware images and without https it's easy to distribute trojanized images in certain cases. You can use Let's Encrypt which for ease and free-of-charge.

Have a look at https://certbot.eff.org/ for the setup.

Replace Riot with Mattermost link in Communication page

Seems that Riot/Matrix (#libremesh-dev:matrix.guifi.net federated with other Matrix servers) is not accepted as official chatroom, while Mattermost (on https://mattermost.altermundi.net) is the official one (ref)

The blocking problem is that:

For the public chatroom both registration and invitation is required. There is no way to ask for an invitation in the mattermost interface. This should be changed in order to have a public, official and accesible chat IMHO (ref)

After this, we will need to include the Mattermost link also in lime-packages readme and other occurrences of the contact details.

Build instructions suggest disabling erroneous feed locations. Why?

From https://libremesh.org/development.html:

Optionally, deselect erroneous feeds locations:

• Image configuration → Separate feed repositories → Enable feed libremesh
• Image configuration → Separate feed repositories → Enable feed profiles

Why should one deselect the libremesh feed? Isn't that where the Libremesh default packages should be coming from?

If we should be enabling everything except the libremesh and 'profiles' feeds when building, I'd like to clarify the wording. The parent commit, 57df50b, isn't clear why this is worded this way.

diff --git a/development.txt b/development.txt
index 1fefa26..4afbd2a 100644
--- a/development.txt
+++ b/development.txt
@@ -101,7 +101,7 @@ Check out the +target+ (e.g. +ATH79+), +subtarget+ (e.g. +generic+) and +profile
 Select the _Target System_, _Subtarget_ and _Target Profile_ accordingly.
 
 
-Optionally, **deselect** erroneous feeds locations:
+Optionally, **deselect** all feed locations except for the correct ones (this prevents upstream packages from taking priority):
 
 - Image configuration → Separate feed repositories → Enable feed libremesh
 - Image configuration → Separate feed repositories → Enable feed profiles

Does Jekyll via Docker work for you?

On my laptop, executing Docker as in the readme but as root, I get an error:

sudo su -
systemctl start docker.service
systemctl start docker.socket
cd lime-web
export JEKYLL_VERSION=3.5
docker run --rm \
        --publish 4000:4000 \
        --volume="$PWD:/srv/jekyll" \
        -it jekyll/jekyll:$JEKYLL_VERSION \
        jekyll serve

Could not find gem 'asciidoctor (~> 1.5.0)' in any of the gem sources listed in your Gemfile.
Run `bundle install` to install missing gems.

I have asciidoctor gem locally installed but shouldn't be relevant.
Likely there's some incompatibility between our Gemfile and official Jekyll Docker image.

Was adding Nanostation M5 xw as supported intentional?

Hi, I am working on a community mesh and in the process of looking for easily available nodes to test on, I saw that the hardware page lists both the NSM5 xm and the xw. The OpenWRT page for the NSM5, and a still open issue in the OpenWRT trac hint that there may be problems with eth0 going down and not coming back up on the xw variant (xm looks like it would work 100%, but finding one seems impossible).

Looking at the history, it looks like @ilario added the xw to the list in 760f9c9. Perhaps him or someone else knows the status of the xw?

I was curious if the xw was tested and found to be fixed (the last comment on the trac issue hints at a fix), or whether this was a mistake when moving around this information. If the latter, it might be good to remove it until someone can say whether it's stable or not. If the former, I'd love to have some confirmation because it would be nice to be able to grab the NSM5 on display at microcenter and start trying out LibreMesh.

add links to vim guide

@panosnethood added a nice vim guide in #45 following the discussion on libremesh/lime-packages#258. This guide is not yet linked anywhere. It should be linked in the other guides where editing a text file is requested.

Add info on the online project meetings

As suggested by @pedro-nonfree here:
https://lists.autistici.org/message/20221123.102456.ea916e81.en.html

Update layer 3 protocol

We should state that the default is babel. Morover we can say that different layer 3 protocols can be used.
At least we should update howitworks.html

Reminder: update development instructions to OpenWrt 19.07-specific packages

Follow-up from #103

When the build instructions will suggest to compile based on OpenWrt 19.07, we have to remember to suggest the users to select batctl-default instead of batctl. Additionally, the fft-eval package is finally available and should be included in the suggested packages list.

libremesh.org uses an expired certificate, making site impossible to load

Common Name (CN)	libremesh.org
Organization (O)	<Not Part Of Certificate>
Organizational Unit (OU)	<Not Part Of Certificate>
Issued By

Common Name (CN)	Let's Encrypt Authority X3
Organization (O)	Let's Encrypt
Organizational Unit (OU)	<Not Part Of Certificate>
Validity Period

Issued On	Wednesday, May 16, 2018 at 6:57:26 PM
Expires On	Tuesday, August 14, 2018 at 6:57:26 PM

Please clarify the differences between the default/mini/zero builds

I think it would be helpful to briefly identify the differences between the compiled image types,
on pages with links to the compiled images.

Example only, probably wrong

• default: for access points with 8MB flash
• mini: for access points with 4MB flash. Lacks ppp support & opkg package manager
• zero: for access points with 4MB flash. Lacks ppp support & UI

Or perhaps a link to the differences: https://github.com/libremesh/lime-sdk/blob/master/flavors.conf

https://github.com/libremesh/lime-web/blob/e37588650a94eaeab44ce2d8246e097886e18d6a/getit.txt#L8

https://github.com/libremesh/lime-web/blob/e37588650a94eaeab44ce2d8246e097886e18d6a/docs/en_quick_starting_guide.txt#L12

troubleshooting dhcp - point to the actual design/problem/technical docs

Is this considered a bug? Should we point to the issue with a link. Anyone knows?

https://github.com/libremesh/lime-web/blob/master/docs/en_troubleshooting.txt#L9-L11

cannot access docs via web

What is the supposed way to access docs via web interface?

Fix lime-example link

in this page: http://libremesh.org/docs/en_config.html
this link doesn't work:

https://github.com/libremesh/lime-packages/blob/develop/packages/lime-debug/files/etc/config/lime-example

HTTPS broken, site not accessible without bypassing security warning

No one can view www.libremesh.org without bypassing a security warning. This means some people won't visit the site, and today is the launch of our space on TranslateWiki.net, so it's a good day to have an easily viewable website.

Test and document how to restrict access to local hosts outside of WAN

Topic started on the mailing list, see first email and my attempt of solution which seems that does not work.

A plus would be to block the connections originating from the mesh (and with destination the local hosts out of the mesh, see figure) but to allow the connections originating from the local hosts (and with destination the hosts in the mesh).

A scenario (actually happened) is an institution willing to expand the mesh and to use it for accessing sensors (connected to the mesh). The institution wants to access the sensors but does not want the rest of the mesh to access its internal hosts.

This issue is independent from allowing or denying internet access (which would also need some documentation!).

Redirect 404 to homepage

During the web site development we changed some URLs and there are people confused by 404s, for example here.
We could (it's just a proposal, let's discuss this) redirect 404 to the homepage.

generate.sh links to static assets incorrectly in development

After running ./generate.sh on local machine, links to stylesheets incorrectly point to an absolute /css/ directory. The logo referenced in lime.css similarly points to an absolute url("/logo/logo.png") which is not correct locally.

I guess these links work in production but would be nice to have styles and images when developing.

Document how to compile for the LibreRouter with OpenWrt 19.07

As discussed on the Element chat, the patch for the LibreRouter hardware watchdog is not present in OpenWrt 19.07. It should be present in OpenWrt 22.03.
It can be disabled moving a jumper on the motherboard or a patch can be applied during the compilation.
The patch is this one:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=2ad949b11dbaa4c634868d55a4452d5a558776bd
and its usage has to be documented on the website.

Incorrect Mailing Lists URLs in side_nav

http://lists.libre-mesh.org/mailman/listinfo/dev should be https://lists.libremesh.org/mailman/listinfo/lime-dev
http://lists.libre-mesh.org/mailman/listinfo/users should be https://lists.libremesh.org/mailman/listinfo/lime-users

regards

Better way to list supported hardware

Currently we have a very small list of officially supported router models here.

It would be amazing to replace the quite useless table with some general criteria.

For example:

1. OpenWrt support is needed.
2. Routers supported within OpenWrt targets:
   1. ar71xx, yyyy, ... support all LibreMesh features with default configuration
   2. zzzzz, ... support LibreMesh but require manual configuration for just one interface per radio
   3. ttttttt, ... support LibreMesh but the radios does not support ieee802.11s mesh. As an alternative, adhoc, AP and client can be used
   4. nnnnn, .... support LibreMesh but the radios does not support neither ieee802.11s nor adhoc mesh. As an alternative, AP and client can be used
3. The minimum amount of RAM memory is 32 MB
4. The minimum amount of flash memory is:
   1. 8 MB for lime-defaults flavor and network profiles based on it
   2. 4 MB for lime-mini and lime-zero flavors and network profiles based on these

Do you think is possible? @G10h4ck @p4u @nicopace @nicoechaniz @aparcar @dangowrt @altergui

Development page: how to compile 2020.1?

The getit page points to the development page, but the development page does not give anymore instructions for compiling the 2020.1 version released just 3 days ago.
The instructions on that page say to use lime-packages at the 2020.1 branch but this has diverged (in libremesh/lime-packages#835) from the v2020.1 tag which is the release one.

Suggest to select batctl-default

See discussion in the last comments on: libremesh/lime-packages#1028

wpad-mesh-wolfssl gets automatically deselected in menuconfig due to a bug in hostapd Makefile

I am reporting this also on OpenWrt side, as it looks like a menuconfig bug rather than a suboptimal way on how to use it.

Selecting at the same time wpad-basic and wpad-mesh-wolfssl causes a clash of files installation in the compilation process. For this reason the deselection of wpad-basic has been suggested in 6e08d3e

wpad-mesh-wolfssl can be selected in menuconfig and wpad-basic deselected, until here everything ok.

Then when closing and opening again menuconfig, wpad-mesh-wolfssl is not visible

.

But when wpad-basic (or something else) is selected, wpad-mesh-wolfssl appears and is actually selected (as it should be).

The wpad-mesh-wolfssl package is categorized as being inside wpad-mesh-openssl, which makes no sense.

And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from here):

wpad-basic
  [identical part removed]
  VARIANT:=wpad-basic

wpad-mesh-openssl
  [identical part removed]
  DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
  PROVIDES+=wpa-supplicant-mesh wpad-mesh
  DEPENDS+=+libopenssl
  VARIANT:=wpad-mesh-openssl

wpad-mesh-wolfssl
  [identical part removed]
  DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
  PROVIDES+=wpa-supplicant-mesh wpad-mesh
  DEPENDS+=+libwolfssl
  VARIANT:=wpad-mesh-wolfssl

This looks like a bug in some of the Config.in files used by make menuconfig.
Just to support this, I exchanged the order in which wpad-mesh-openssl and wpad-mesh-wolfssl are defined in tmp/.config-package.in and now wpad-mesh-wolfssl and wpad-mesh-openssl are at the same hierarchical level. Makes no sense.

Avoid the addition of non-existing repositories in distfeeds.conf

Compiling LibreMesh with the current instructions results in an image including this /etc/opkg/distfeeds.conf:

src/gz openwrt_core http://downloads.openwrt.org/releases/19.07.4/targets/ath79/generic/packages
src/gz openwrt_base http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/base
src/gz openwrt_libremap http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/libremap
src/gz openwrt_libremesh http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/libremesh
src/gz openwrt_luci http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/luci
src/gz openwrt_packages http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/packages
src/gz openwrt_routing http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/routing
src/gz openwrt_telephony http://downloads.openwrt.org/releases/19.07.4/packages/mips_24kc/telephony

you can see two intruder lines: the one about libremesh (see #728) and libremap, which do not exist and cause an error like:

Problems with opkg update:
 * opkg_download: Failed to download http://downloads.openwrt.org/releases/19.07.4/packages/mipsel_24kc/libremap/Packages.gz, wget returned 8.
 * opkg_download: Failed to download http://downloads.openwrt.org/releases/19.07.4/packages/mipsel_24kc/libremesh/Packages.gz, wget returned 8.

Seems that these lines appear in the distfeeds.conf file because some repositories with this name are mentioned in the feeds.conf file used for the compilation. See:
https://github.com/openwrt/openwrt/blob/947bfc62d003ea54c13470ee6bbc9f20827592b0/package/base-files/Makefile#L201

I think that the good way to fix this is to add in the compilation instructions the following steps (during the make menuconfig section):

Deselect non-existing repositories
- Image configuration -> Separate feed repositories -> Enable feed libremesh
- Image configuration -> Separate feed repositories -> Enable feed libremap

Do you see a cleaner way to do this (e.g. a different way to use the feeds.conf file)?

Please clarify prefixes ap, apname, adhoc for _ssid

The web site does not clearly explain what the ap, apname, adhoc prefixes are used for in the LibreMesh config

Example (probably wrong):

• apname_ssid: Per access point unique SSID to avoid roaming (switching) between various access points that share an SSID
  libremesh/lime-packages@a17e617
• ap_ssid: ?The SSID for consumer device access
  This is used as network / cloud identifier, and therefore BATADV VLAN is based on this setting.
  Access points that share the same ap_ssid will act like a single LAN
• adhoc_ssid: ?The mesh link used between access points

https://github.com/libremesh/lime-packages/blob/develop/packages/lime-docs/files/lime-example

https://github.com/libremesh/lime-web/blob/e37588650a94eaeab44ce2d8246e097886e18d6a/docs/en_config.txt#L103

https://github.com/libremesh/lime-web/blob/e37588650a94eaeab44ce2d8246e097886e18d6a/howitworks.txt#L53

A mention that this is the config lime wifi ap_ssid might make it more clear?

Cheers

Add link to "search in mailing list archive" in Communication page

This would help users to find answers for frequently asked questions.

Refer to discussion on lime-users:
https://lists.libremesh.org/pipermail/lime-dev/2017-August/000969.html

The main problem here is: is it ok to do this with Google search or there's a better way?

Migration to OpenWrt

See libremesh/lime-sdk#48
LEDE is still mentioned in this repository here:
https://github.com/libremesh/lime-web/search?q=lede

Update Development page to include packages selected in LibreRouter repository

In order to keep the Development page useful, it should be updated to the packages selected by the LibreMesh developers.
Seems that they are working on the image compilation for LibreRouter and the packages selection is being made on:
https://github.com/LibreRouterOrg/openwrt/blob/b536696f27b3803041dc7a2327157ef69a76e953/configs/default_config

comparing this file with what gets compiled following the instructions on the Development page, the following things seems to be missing from the development page or from the lime-packages packages dependencies:

CONFIG_PACKAGE_watchping=y
we don't use this anymore, no?

CONFIG_PACKAGE_kmod-tun=y
seems needed by Tinc, but we still are not including any Tinc stuff (e.g. https://github.com/libremesh/lime-packages/tree/master/packages/tinc, libremesh/lime-packages#99, libremesh/lime-packages#579) in the release, correct?

CONFIG_PACKAGE_kmod-iptunnel6=y
CONFIG_PACKAGE_kmod-ip6-tunnel=y
these looks related to BMX6 and BMX7, do we need them?

CONFIG_PACKAGE_fft-eval=y
we have to remember to add this to the page once OpenWrt 19.07 will be released

CONFIG_PACKAGE_deferable-reboot=y
should we consider to include this in the next release? (maybe increasing the time between reboot and reboot to a week)

CONFIG_PACKAGE_batctl=y
beware that with OpenWrt 19.07 the batctl package will split in batctl-tiny, batctl-default and batctl-full

CONFIG_BUSYBOX_CONFIG_DEVMEM=y
CONFIG_KMOD_BATMAN_ADV_DEBUGFS=y
CONFIG_PACKAGE_rpcd-mod-rrdns=y
CONFIG_PACKAGE_kmod-usb-ohci=y
What about these? Do we need them?

Replace references to Chef with https://chef.libremesh.org

https://chef.libremesh.org is now working and replaces outdated Chef

Implement multilanguage support

Migrate to nikola: https://getnikola.com
This is to support multilanguage properly.

Improve list of communities in the home webpage

Please put a link on "Several communities around the world " and link to a page with all known sites, that use libremesh

Setup Multilanguage

Depends on #22

Import and adapt content from old redmine website

Some of the content of the old Redmine website have not yet been copied to the new website and would be useful to have them:
http://old.libremesh.org/projects/libre-mesh/wiki/index

Please tick also the pages with no useful information.

• Antecedents
• Anygw
• Compile Manually
• Configuration
• Ground routing
• ConnectingClouds
• Dhcp route pushing
• Flashing Devices
• Guifi Integration
• ModeA
• Network Architecture
• Objectives
• Parametric options
• Rationale discussions
• Repo
• USB radio
• Versions