qMp.cat about network-profiles HOT 15 CLOSED

Based on what we have been talking with pedro and aparcar, the custom qmp behaviour I would keep it in a custom package, so it can be installed on any image.
so... my suggestion would be:

• set everything all static configs on /etc/config/lime-defaults (in particular, bmx6 vlan tag, protocols enabled, default static ipv4 address)
• do a very simple /etc/config/lime custom web interface

What do you think?

from network-profiles.

@nicopace

do a very simple /etc/config/lime custom web interface

Isn't that part of you first-boot-wizard?

from network-profiles.

@pedro-nonfree there seems to be a package for the qmp proto. Did you had a look at it? Maybe I can simply extend the functionality

https://github.com/libremesh/lime-packages/tree/develop/packages/lime-proto-qmp

from network-profiles.

@aparcar looks great place to implement the init behavior, and adjust required stuff

https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto-qmp/src/qmp.lua#L16-L22

https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto-bmx6/src/bmx6.lua#L157-L164

from network-profiles.

@pedro-nonfree,

On WAN zone / to the community network, it uses a random IPv4 (where is the random algorithm? help @p4u @rogerpueyo) so it can communicate temporarily with other nodes and access shared Internet. After that, we try to take a valid guifi IPv4 so it can connect to all guifi network

There is a predefined prefix (10.202.0.), to which you append a random integer between 1 and 255, and a /32 netmask.

from network-profiles.

IMO there should be a package for qmp which includes a set of dependencies and a lime-defaults file (as it is right now). Only bmx6 should be enabled on this setup (see kollserola network-profile as example of configuration), not batman-adv nor anygw.

In addition there should be network-profiles for each zone (cloud) of qMp, like "qmp-sants" or "guifi-qmp-sants" (refering to http://sants.guifi.net). This network profile should include a uci-default script (see network profiles like the ones from libremesh as an example) which modifies lime-defaults on first boot. This modification should be (among other things) WiFi Channel, WiFi SSID, and Network Address space (the one assigned by the guifi.net web site). Network Adress can be defined as (for instance) 10.9.0.0/27/16 which means a random /27 inside 10.9.0.0/16.

The network profile should include a file named PACKAGES on the root of the sub-profile (i.e guifi-qmp-sants/nanostation/PACKAGES) which includes lime-proto-qmp and disables other non-used packages if necessary.

from network-profiles.

@p4u
the lime-proto-qmp looks very simple, does it already offer any functionality?

@pedro-nonfree @rogerpueyo

10.9.0.0/27/16 which means a random /27 inside 10.9.0.0/16.

Does random work for the setup? If LiMe should be fully Guifi compatible it must use a static IP chosen by the Guifi website afaik.

from network-profiles.

@aparcar
This is something to be discussed on guifi-mesh mailing list but IMO the most important thing for any QMP guifi.net network is to be able to participate in the network. I mean, the whole QMP-Guifi-Sants mesh cloud shares the same IPv4 space (in this specific case three subnetworks, i.e 10.1.8.0/21, see here [1]). So the BGP border nodes announce these IPs to the whole Guifi.net network making the interconnection possible. If a node does not have a valid IP address of this range, it will be able to connect with the same cloud nodes but not with the ones outside.

So my point is, let's use a random IPv4 range for initial IP assignment, so the setup will work out-of-the-box. And later ask the user to register a node on http://guifi.net to get a specific/uniq IPv4/27 range which will be manually configured on the node (via LuCi).

This might be a temporay/initial approach for using generic LiMe firmware images. Second step would be to implement (as chef did) customized firmware images. So the user can specify its previously registered IPv4/27 range on the imagebuilder web interface. So the resulting binary will be already configured.

[1] https://guifi.net/ca/sants-lescorts

from network-profiles.

@aparcar did an image for qmp in libremesh that I'm trying to make it work. Seems that by default works in channel 165, but my network use 132 (20 MHz) or 132+ (40 Mhz) adhoc which is working in qmp 3.2.1

trace

root@qMp-b54fbc:~# cat /etc/config/lime | grep 165
	option channel_5ghz '165'
root@qMp-b54fbc:~# bmx6 -c interfaces
interfaces:
devName        state type     rateMin rateMax llocalIp                     globalIp                             primary 
br-lan         UP    ethernet 1000M   1000M   fe80::822a:a8ff:feb5:4fbc/64 fd66:66:66:6:822a:a8ff:feb5:4fbc/64  0       
eth0.2         UP    ethernet 1000M   1000M   fe80::822a:a8ff:feb5:4fbc/64 fd66:66:66:9:822a:a8ff:feb5:4fbc/64  1       
wlan0-adhoc_12 UP    ethernet 54000   54000   fe80::802a:a8ff:feb4:4fbc/64 fd66:66:66:13:822a:a8ff:feb4:4fbc/64 0       
wlan0-mesh_12  UP    ethernet 54000   54000   fe80::822a:a8ff:feb4:4fbc/64 fd66:66:66:12:822a:a8ff:feb4:4fbc/64 0       
root@qMp-b54fbc:~# sed -i s/165/132/ /etc/config/lime
root@qMp-b54fbc:~# lime-config 
Clearing wireless config...
Clearing network config...
Disabling odhcpd
Cleaning dnsmasq
Disabling 6relayd...
Configuring system...
Let uhttpd listen on IPv4/IPv6
root@qMp-b54fbc:~# lime-apply 
Apply hostname
Reload network config
Reload ALFRED
Reload routing protocols
/etc/init.d/alfred: starting alfred
/etc/init.d/alfred: starting batadv-vis
/etc/init.d/alfred: waiting 30 secs for br-lan address...
root@qMp-b54fbc:~# bmx6 -c interfaces
interfaces:
devName        state type     rateMin rateMax llocalIp                     globalIp                             primary 
br-lan         UP    ethernet 1000M   1000M   fe80::822a:a8ff:feb5:4fbc/64 fd66:66:66:6:822a:a8ff:feb5:4fbc/64  0       
eth0.2         UP    ethernet 1000M   1000M   fe80::822a:a8ff:feb5:4fbc/64 fd66:66:66:9:822a:a8ff:feb5:4fbc/64  1       
wlan0-adhoc_12 DOWN  INACTIVE 54000   54000   fe80::802a:a8ff:feb4:4fbc/-1 fd66:66:66:13:822a:a8ff:feb4:4fbc/-1 0       
wlan0-mesh_12  DOWN  INACTIVE 54000   54000   fe80::822a:a8ff:feb4:4fbc/-1 fd66:66:66:12:822a:a8ff:feb4:4fbc/-1 0   

I cooked the image myself this way: https://github.com/guifi-exo/wiki/blob/master/howto/libremesh.md#build-a-libremesh-that-is-compatible-with-qmp

but with wireless.radio0.country='TZ' the list of wifis does not include 132:

from network-profiles.

@rogerpueyo What are the appropriate snippets and in what order? I know you are using lime-sdk to build qMp, where can I find your receipt? Or can you provide me?

Or alternatively here you have my receipt do you find something wrong? https://github.com/guifi-exo/wiki/blob/master/howto/libremesh.md#build-a-libremesh-that-is-compatible-with-qmp

from network-profiles.

At the end of this post you've got the "clone&download&build&cook" sequence for qMp http://qmp.cat/News/35_qMp_4.0_Macondo_released. Do the same with LibreMesh, running any required snippet before building.

from network-profiles.

Thanks a lot for your help @aparcar @rogerpueyo now I have an antenna with libremesh talking qmp dialect (testing, not for production usage)

Here is the documentation updated: https://github.com/guifi-exo/wiki/blob/master/howto/libremesh.md#build-a-libremesh-that-is-compatible-with-qmp

As you may notice, I did some suggestions in different stuff of libremesh. Let's hold this open because at the moment I'm in testing phase.

from network-profiles.

(now there is a production node with libremesh, let's wait some days to see if everything is OK)

qmp nodename ends with the last 4 characters of mac address and primary ipv6 address. This is useful when you are matching mac address of "associated stations" (status page) with "mesh nodes", this way you can know your near nodes.

• How can we put this as the name of node
• Is there an alternative method?

from network-profiles.

@pedro-nonfree did you continue the testing?

from network-profiles.

Yes, I have a node up and running in production with libremesh for some weeks and works fine (is more unstable the hardware than the software, hehe). I will close the issue. Thanks to all for the support

from network-profiles.