lime-dev October 2018

lime-dev@lists.libremesh.org

3 participants
2 discussions

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, 1 month

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!

6 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev October 2018