lime-dev

lime-dev@lists.libremesh.org

338 discussions

by Paul Spooren

Hi all, it's been a very long time since we had a LiMe release, and currently the state of master isn't the best, right? What do you think of the following: We determine a LibreMesh setup fitting most purposes, say Anygw, Batadv, BMX7, lime-app. Now we make sure this setup works, sure we have more modules and packages, but we focus for a time on these few packages and make them work. Now, we kindly ask to get these packages in the official repository of OpenWrt, just like Freifunk did in the past. Now it's suddenly super easy to build LibreMesh, as it's fully compatible to the official SDK. Once the setup works we can make a new release, saying that the combination of packages above (or a similar one) is officially supported, the rest is considered "unstable" as long as not in the official repo. Would be happy to work on this for the next weeks until we have something stable. What do you think? Sunshine, Paul

6 years, 5 months

Re: [lime-dev] Extracting full mesh topology of BMX6

by Mark Birss

Should I then be able to build meshrc firmware using the Beta Chef web builder and selecting the meshrc-node profile only ? https://as-test.stephen304.com/chef/ Regards On Sat, 10 Nov 2018, 16:08 Paul Spooren <mail(a)aparcar.org wrote: > You could have a look at meshrc found here: > https://github.com/aparcar/meshrc > > It's an interface that does long term monitoring of a mesh network based > on bmx7 using some lightweight lua scripts. > > On Nov 9, 2018 22:03, David Johnson <david.lloyd.johnson(a)gmail.com> wrote: > > > > I'm using Libremesh version openwrt-18.06 > > > > I want to extract the topology of the mesh in a json format for some > > visualization software we are building. What do you suggest is the > > best way of doing this > > > > BMX6 version is: > > BMX6-0.1-alpha comPatibility=16 > > revision=0312168aaa384379ccbefd4b2d936fc698664d5b > > > > So far I've tried > > - opkg install bmx6-topology to try and use the topology plugin ... > > but this doesn't exist on this libremesh release > > - Using the b6m-jsonp script > > https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp > > > > But logread shows: > > user.notice b6m-jsonp: ERROR: globalId not found, abort > > > > So this version of BMX6 is not exporting that $globalId > > > > Any suggestions > > > > Thanks > > David > > > > -- > > Dr David Johnson > > Director, Ammbr Research Labs South Africa > > Part of the AmmbrTech Group > > http://www.ammbrtech.com > > > > Adjunct Senior Lecturer > > ICT4D, Computer Science Department > > University of Cape Town > > https://people.cs.uct.ac.za/~djohnson/ > > _______________________________________________ > > lime-dev mailing list > > lime-dev(a)lists.libremesh.org > > https://lists.libremesh.org/mailman/listinfo/lime-dev > _______________________________________________ > lime-dev mailing list > lime-dev(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-dev

6 years, 11 months

Re: [lime-dev] Extracting full mesh topology of BMX6

by Paul Spooren

You could have a look at meshrc found here: https://github.com/aparcar/meshrc It's an interface that does long term monitoring of a mesh network based on bmx7 using some lightweight lua scripts. On Nov 9, 2018 22:03, David Johnson <david.lloyd.johnson(a)gmail.com> wrote: > > I'm using Libremesh version openwrt-18.06 > > I want to extract the topology of the mesh in a json format for some > visualization software we are building. What do you suggest is the > best way of doing this > > BMX6 version is: > BMX6-0.1-alpha comPatibility=16 > revision=0312168aaa384379ccbefd4b2d936fc698664d5b > > So far I've tried > - opkg install bmx6-topology to try and use the topology plugin ... > but this doesn't exist on this libremesh release > - Using the b6m-jsonp script > https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp > > But logread shows: > user.notice b6m-jsonp: ERROR: globalId not found, abort > > So this version of BMX6 is not exporting that $globalId > > Any suggestions > > Thanks > David > > -- > Dr David Johnson > Director, Ammbr Research Labs South Africa > Part of the AmmbrTech Group > http://www.ammbrtech.com > > Adjunct Senior Lecturer > ICT4D, Computer Science Department > University of Cape Town > https://people.cs.uct.ac.za/~djohnson/ > _______________________________________________ > lime-dev mailing list > lime-dev(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-dev

6 years, 11 months

Extracting full mesh topology of BMX6

by David Johnson

I'm using Libremesh version openwrt-18.06 I want to extract the topology of the mesh in a json format for some visualization software we are building. What do you suggest is the best way of doing this BMX6 version is: BMX6-0.1-alpha comPatibility=16 revision=0312168aaa384379ccbefd4b2d936fc698664d5b So far I've tried - opkg install bmx6-topology to try and use the topology plugin ... but this doesn't exist on this libremesh release - Using the b6m-jsonp script https://gitlab.com/sim6/sim6s-b6m/blob/master/www/cgi-bin/b6m-jsonp But logread shows: user.notice b6m-jsonp: ERROR: globalId not found, abort So this version of BMX6 is not exporting that $globalId Any suggestions Thanks David -- Dr David Johnson Director, Ammbr Research Labs South Africa Part of the AmmbrTech Group http://www.ammbrtech.com Adjunct Senior Lecturer ICT4D, Computer Science Department University of Cape Town https://people.cs.uct.ac.za/~djohnson/

6 years, 11 months

fd66:66:66:7:c693 IPv6 unaccessble but 2a00:1508:ac6:d000:: works ok

by Piotr Barszczewski

Hello, I’ve initially asked my question at https://github.com/libremesh/lime-sdk/issues/93 but have been redirected to this mailing list and I hopie this is the right place to ask. I'm trying to figure one thing out and can't wrap my head around it - maybe someone could help me with it. I create a small mesh network (2-7 devices) and it works fine initially. I connect with my PC to it and can ssh/ping and open LuCi over IPv4 and IPv6 addresses in IPv6 fd66:66:66:7:c693:ff: subnet (which is shown in LuCi under http://thisnode.info/cgi-bin/luci/status/bmx6/Nodes ) and 2a00:1508:ac6:d000:: (which is my option main_ipv6_address '2a00:1508:0a%N1:%N200::/64' in /etc/config/lime). After around an hour of working the fd66:66:66:7:c693:ff: address become's unavailable and only 2a00:1508:ac6:d000:: works. This only fixes after I reconnect to the Mesh Wifi network from my PC. I'm totally ok with using main_ipv6_address but LuCi bmx6/nodes shows only addresses from fd66:66:66:7:c693:ff: subnet which makes it very hard for end user to know what is the actual address of specific device (not to mention obtaining it's IPv4 address). Is there a way around this, eg. forcing Luci to show only the 2a00:1508:ac6:d000:: address or how to make fd66:66:66:7:c693:ff: not disappear after a while? For me this would be ideal scenario because figuring the IP address of each node is difficult - I understand how it’s calculated from MAC address but still looking for a single place which would list all the nodes addresses from 2a00:1508:ac6:d000:: subnet. I’m building the image from Lime-SDK commit https://github.com/libremesh/lime-sdk/commit/c3385846bf74d9b7530bc333f59fef… (because of https://github.com/libremesh/lime-sdk/issues/85) and with these packages: src-git base https://github.com/lede-project/source.git^01a8f0e444c9b52f100eff878cc7011f… src-git packages https://git.openwrt.org/feed/packages.git^1df38a4495a5eae7e39d10b93b3c7264a… src-git luci https://git.lede-project.org/project/luci.git;lede-17.01 src-git routing https://git.lede-project.org/feed/routing.git;lede-17.01 src-git telephony https://git.lede-project.org/feed/telephony.git;lede-17.01 src-git libremesh https://github.com/libremesh/lime-packages.git;17.06 src-git libremap https://github.com/libremap/libremap-agent-openwrt.git;master src-git limeui https://github.com/libremesh/lime-packages-ui.git;master + my own repo for app with a REST API Target is ar71xx/generic and profile is carambola2. I can repeat exactly the same for https://downloads.libremesh.org/dayboot_rely/17.06/targets/ar71xx/generic/c… when flashed with lede-17.01.2-lime-default-ar71xx-generic-carambola2-squashfs-sysupgrade.bin - just ping the 2a00:1508:ac6:d000:: and fd66:66:66:7:c693:ff: and after 30-60minutes the fd66:66:66:7:c693:ff: will become unavailable but 2a00:1508:ac6:d000:: will work just fine. Best regards, Piotr Barszczewski

6 years, 11 months

FirstBootWizard Description for Hackathon in Quintana

by Nicolas Pace

Hi! As there is going to be a hackathon in Quintana in the upcoming weeks, I was invited to share the progress of the FirstBootWizard (FBW) project. https://github.com/libremesh/FirstBootWizard/ The question it tries to reply is: * How is a new network setted up? What is the first boot experience when a LibreMesh node is turned on? * How do a LibreMesh node joins an existing network? The approach is for nodes (routers) to share their network config with their peer nodes, so they can decide on whether they want to join their network. There are a lot of complexities about this: * hardware differences: original node had a set of radios, antennas and wired interfaces, and mine has a different one, * physical conditions: which radio and which antenna of that radio fetched the config from my peer node?, and what if the radios were configured specifically based on the context of that node? (location, neighbours, etc). * logical roles: one node can be an batman's alfred's coordinator, a gateway with manual configurations, or even have static ip addresses or centralized services running on them... * customization: how do we split config between node config and network config in a way that allows for customization and yet maintainability These are the boundaries that we defined for the first iterations: * We will design for the LibreRouter context first: as it is close to getting released, and this is part of the first experience, needs to be available asap, so we will narrow the focus to implement first the features required for it, then generalize (in this case, triple radios for example). * We will priorize the cases of: 1. One new node in an existing network: because that is the most common case, 2. First node of a network: because this is the inception moment, that will also happen a lot. Some other cases that were not taken into consideration but are part of the process: 3. different frequencies for different radios: the LR has two 5ghz, and it is desired that both have different radios so there is no self-inflicted noise. So, the configs will reflect that and need to consider this situation. 4. Border node of a network: it may happen that a node is put in to communicate to networks with each other 5. TVWS case: The 2.4ghz radio being used with the TVWS Frequency shifter (basically, a device that turns a 2.4ghz radio into a 600Mhz one, capable of non-line-of-sight links). No special considerations yet in my mind, but still to be considered. 6. Extra packages needed: the lime config doesn't include the potential extra packages that might have been installed on a firmware, 7. Attended upgrades server: this is key, as if there is one in your network, you might do that before anything else (as it will have the extra packages installed for example). What has been done already (you can find it in the github repo: https://github.com/libremesh/FirstBootWizard/ ): * serve-lime-config shares the lime-default with the network over http, so anyone can fetch it. It is a symlink for the lime-defaults file to a publicly accesible folder shared by uhttpd. * first-boot-wizard-daemon: a daemon that while in setup state (defined by the presence of the /var/lock/first_run file) keeps searching for nodes and fetching their config. The basic behaviour is: * no network config found around, keeps searching * one network config found around, applies its config and reboots removing first_run file * many networks config found around, don't do anything, and keeps them so the user can choose It also includes a ubus service to ask for the network config files found around, so the user can choose which to join, or trigger it in a latter moment if we want to reset the config to 'network defaults', and also the ability to create a new network. These are the foundations to add support in the lime-app. Caveats: * are there anything within the lime-default file that we don't want to be sharing openly within the adhoc/11s network? * what is the UX we will provide is a password is needed? Hope this is enough info to work on it! Will be around if any questions appear, through here, Riot, Telegram, etc. good luck!

7 years

Expired certificate at https://libremesh.org

by amuza

Hi devs, Nothing else, just the title. Cheers!

7 years

Adding a custom ipk file when cooking

by David Johnson

How do I add a customised ipk file to the cooker. I just compiled a slightly modified bmx6-sms plugin with an increased sms length size for the ar71xx/generic target and I want to cook some firmware for a few different ar71xx/generic profiles using this modified ipk file. Thanks David

7 years, 1 month

rethinking network-profiles

by Paul Spooren

Hi all, some time ago I had the (bad) idea to convert network profiles into opkg packages to automatically re-install them after an sysupgrade. Also allow upgrading of network-profiles in case something changed. However, this doesn't work so well as the file `lime-defaults` is provided by `lime-system` as well as any network package. This results in the following error: Collected errors: * check_data_file_clashes: Package zz-qmp-v1 wants to install file /home/aparcar/worker/imagebuilder/lime/17.06/ar71xx/generic/build_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/etc/config/lime-defaults But that file is already provided by package * lime-system * opkg_install_cmd: Cannot install package zz-qmp-v1. make[2]: *** [package_install] Error 255 Makefile:120: recipe for target '_call_manifest' failed make[1]: *** [_call_manifest] Error 2 Makefile:201: recipe for target 'manifest' failed make: *** [manifest] Error 2 So, what to do? We could introduce yet another config file, so people with network-profiles wouldn't fiddle with the `lime-defaults` file but with `network-profile` or something, which would be "a layer between" `lime` and `lime-defaults` config. Another approach would be to get rid of the `lime-defaults` per default, and rely on sane defaults in the modules. The lime-config module already support a fallback aka default value, in case the setting is neither found in `lime` nor `lime-defaults`. Lastly, and my favorite, we could convert all `network-profiles` in (a single) uci-defaults file. Individual options are set via uci, if special files like `authorized_keys` are required, it's possible via `cat EOF <>` magic. This approach would a) allow to be easy to handle via the image-server, which then just stores these single text files, and b) easy to transport to the image server. An additional field in chef could be added called "uci-defaults" where the user simply paste in desired uci settings. Eventually a more sophisticated Chef version would allow to automatically generate a single "uci-config" containing IPs, SSH keys, whatever, all set via the web interface and requested via the generic image server API. Versioning could be done via a hash of the config file, meaning, if the hash is different from the upstream version, update. The `lime` config file would have a new field called `network-profile` or something similar, maybe an URL pointing to the latest uci-config, which is then requested on every build-request. Understandable? Greetings from Nikko, Japan, Paul

7 years, 1 month

Little "bug" in Librenet6 documentation commands

by al

Hello! Working with Librenet6 configuration I found a scenario where the documentation go to an error that at the beginning is hard to understand why. In Unix systems "hostname" could be an alphanumeric and accept the hyphen ('-')[1], but Tinc "Name" accept alphanumeric and the underscore ('_')[2], not the hyphen. So, there is a scenario not much uncommon where we could have a hostname with hyphens like "virtual-server-1" or "LiMe-0C9B". So, those parts in documentation could became in a bug: In Debian based: Name = host_$(hostname) In OpenWrt based: HOSTNAME=$(uci get system.(a)system[0].hostname) [0] I have permissions for change the documentation and fix that issue, but I want to talk with you about it because my fix proposal change the way of naming hosts (beginning with an "host_" or "topo_") and it could affect some of others of your scripts: As is written in Tinc manual I think that they have knowledge about this possible collision between to ways of naming hosts. So the manual says: "If Name starts with a $, then the contents of the environment variable that follows will be used. In that case, invalid characters will be converted to underscores. If Name is $HOST, but no such environment variable exist, the hostname will be read using the gethostname() system call."[2] About tinc environment variables[3]. So my proposal is changing from Name = host_$(hostname) # bash variable or Name = topo_$HOSTNAME # bash variable to Name = $HOST # tinc environment variable (And in the file names) result: "host_myniceserver" to "myniceserver". "host_virtual-server-1" (that will fail) to "virtual_server_1" "topo_LiMe-0C9B" (that will fail) to "LiMe_0C9B" But in this case we lost info about if the host came from Debian/Ubuntu manual (host_) or came from OpenWrt manual (topo_). What do you think? Also we made an script for my machines that we can share, off course is in case of an script that this standardization process has sense. Regards. [0] http://docs.altermundi.net/LibreNet6/Setup [1] As wrote in RFC 952 and RFC 1123 [2] http://www.tinc-vpn.org/documentation-1.1/Main-configuration-variables.html Name = <name> [required] This is a symbolic name for this connection. The name must consist only of alfanumeric and underscore characters (a-z, A-Z, 0-9 and _), and is case sensitive. [3] http://www.tinc-vpn.org/documentation/Scripts.html#index-environment-variab… ($HOST environment variable (and maybe others) are not documented)

7 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev