Hi!
In order to have wireless WAN, should I configure everything through
/etc/config/lime-node ?
Please see what what I did and some comments:
config wifi radio0
list modes 'client'
option channel 'auto'
option client_ssid 'com-ssid'
option client_key 'private-ssid'
option client_encryption 'private-password'
config net wirelessclientWAN #0
option linux_name 'wlan0-sta' #1
lists protocols 'wan'
config net lm_hwd_openwrt_wan
option autogenerated 'false'
#0 Is this line correct?
#1 This name, wlan0-sta, I made it up, I could not find any -sta word
when when running wifi status. How could I find this name?
After saving that lime-node configuration, I run lime-config and got
this:
root@MT-8a5938:~# lime-config
/usr/bin/lua: /usr/lib/lua/lime/config.lua:122: attempt to index local
'high_pt' (a nil value)
stack traceback:
/usr/lib/lua/lime/config.lua:122: in function 'uci_merge_files'
/usr/lib/lua/lime/config.lua:169: in function 'uci_autogen'
/usr/lib/lua/lime/config.lua:195: in function 'main'
/usr/bin/lime-config:55: in main chunk
[C]: ?
root@MT-8a5938:~#
root@MT-8a5938:~#
root@MT-8a5938:~# lime-config
Cannot acquire lock on /var/run/lime-config.pid
This may be caused by lime-config already running or unexpectedly crashed.
If it is the latter case (check carefully!) try by deleting the lock
file with:
# rm -rf /var/run/lime-config.pid
Before running lime-config again
How should I configure a wireless WAN?
Thanks!
Hi all!
I'm experiencing some trouble in dns resolution over ipv6 and I hope
someone can help me!
I'm using the lime packages at version 2020.1 with this configs
https://github.com/libremesh/network-profiles/blob/master/valsamoggia.ninux…
with this packages
https://github.com/libremesh/network-profiles/blob/master/valsamoggia.ninux…
and deselecting these packages
-dnsmasq
-firewall
-odhcpd-ipv6only
-odhcpd
-ppp
* note: I don't know if it's a problem but i can deselect the Base
System > firewall for ath79xx, but not in example for ar71xx e bcm63xx
* note: Not sure if i should also remove odhcp6c
and i just keep the ipv6 configs from previuos versions:
option main_ipv6_address '2a00:1508:0a%N1:%N200::/64'
Now, I'm with an ISP that don't provide ipv6
and some connections fails because the DNS request goes first to ipv6
address, failing, and then to ipv4
Is a good idea trying to remove ipv6 from the network?
Can i experience issues connecting to other nodes with ipv6 enabled?
Is there a risk of compromise the working of the mesh?
If no, will be enough to remove main_ipv6_address from lime-community?
Thanks in advance if for any advice!
Here are some demonstrations:
$ ping google.com
PING google.com(mil41s02-in-x0e.1e100.net (2a00:1450:4002:404::200e)) 56
data bytes
From ninux-561d87 (2a00:1508:afe:c00::871d:5600) icmp_seq=1 Destination
unreachable: Unknown code 5
From ninux-561d87 (2a00:1508:afe:c00::871d:5600) icmp_seq=2 Destination
unreachable: Unknown code 5
From ninux-561d87 (2a00:1508:afe:c00::871d:5600) icmp_seq=3 Destination
unreachable: Unknown code 5
^C
--- google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms
$ ping4 google.com
PING (142.250.184.46) 56(84) bytes of data.
64 bytes from mil41s02-in-f14.1e100.net (142.250.184.46): icmp_seq=1
ttl=115 time=78.2 ms
64 bytes from mil41s02-in-f14.1e100.net (142.250.184.46): icmp_seq=2
ttl=115 time=79.4 ms
64 bytes from mil41s02-in-f14.1e100.net (142.250.184.46): icmp_seq=3
ttl=115 time=77.7 ms
^C
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 77.741/78.470/79.432/0.709 ms
With wget i see it tries to resolv firstly ipv6 and then ipv4
$ wget google.com
Resolving www.google.com (www.google.com)... 2a00:1450:4016:803::2004,
172.217.22.196
Connecting to www.google.com
(www.google.com)|2a00:1450:4016:803::2004|:80... failed: Permission denied.
Connecting to www.google.com (www.google.com)|172.217.22.196|:80...
connected.
HTTP request sent, awaiting response... 200 OK
And if my pc i manually remove the ipv6 nameserver leaving only
10.170.0.1 from /etc/resolv.conf
the requests go only in ipv4 and stop failing
$ cat /etc/resolv.conf
# Generated by NetworkManager
search valsamoggia.ninux.org
nameserver 10.170.0.1
nameserver fe80::a8aa:aaff:fefe:caa%wlo1
nameserver fe80::c6ea:1dff:fea3:b68%wlo1
This is the status of the lime-app, showing the ipv6 addresses assigned
System
Uptime 5 hours, 34 minutes, 25 seconds
Device ADB P.DG A4001N
Firmware LiMe 2020.1 development (2020.1 rev. 002a53c 20210603_0623)
Internet connection
✔ IPv4 ✘ IPv6 ✔ DNS
IP Addresses
IPv4 10.170.157.135/16
IPv6 2a00:1508:afe:c00::871d:5600/64
IPv6 fe80::bef6:85ff:fe56:1d87/64
--
gothos
PGP Key ID: 0x6406B32F2CEC0008
PGP Key server: https://keys.openpgp.org/
For your information, an interesting feature of Babeld:
-------- Forwarded Message --------
Subject: [Babel-users] HOWTO: MAC security for Babel
Date: Tue, 08 Jun 2021 14:13:37 +0200
From: Juliusz Chroboczek <jch(a)irif.fr>
To: babel-users(a)lists.alioth.debian.org
Dear all,
A quick tutorial on protecting your Babel network with cryptographic
signatures using the Babel-MAC protocol extension.
0. What does MAC security do?
=============================
It protects your Babel infrastructure by preventing an attacker from
impersonating a Babel router by either spoofing Babel packets or replaying
old Babel packets.
It does not encrypt your Babel traffic: Babel packets are signed, not
encrypted. This means that tcpdump and wireshark can still be used for
debugging.
It is cheap: you should not see a significant increase in CPU load due to
MAC protection, and the per-packet overhead is moderate (51 bytes for
SHA-256, 35 bytes for Blake2s-128). It also does not significantly slow
down neighbour acquisition: the initial cryptographic handshake is just
one packet exchange.
It does not protect your non-Babel traffic: for example, it doesn't
prevent an attacker from sending data packets from a spoofed IP address;
you still need to rely on higher-level (HTTPS, SSH, etc.) or lower-layer
(WPA3, OpenVPN, Wireguard) mechanisms for that. However, since Babel-MAC
will prevent an attacker from spoofing their location in the network
(which router they're using to access the network), it will make it easier
to find the attacker and kindly explain to them that there's a bug
somewhere. (In no case do we condone the use of physical violence.)
MAC security is implemented in babeld master since 2021-05-31 and BIRD
master since 2021-06-06.
1. Generate a key
=================
Babel-MAC is vulnerable to brute-force attacks, so you should use a strong
key. The best way is to generate a random key:
dd if=/dev/random bs=32 count=1 | xxd -ps -c32
The security of Babel-MAC relies on this key only being shared with people
authorised to announce Babel routes.
2. Install the key on your routers
==================================
Babeld
------
On each router running babeld, add the following to the configuration file:
key id k1 type hmac-sha256 value fe3c...
default key k1
replacing fec3... with your secret key. This will enable MAC protection
on all interfaces (you will still need to enable the interfaces, either
from the config file or from the command line).
Alternatively, you may enable MAC protection on just some interfaces:
key id k1 type hmac-sha256 value fe3c...
interface eth0
interface wlan0 key k1
Note that babeld supports using multiple configuration files (specify the
'-c' option multiple times), but will not reload the files automatically
(you'll need to restart babeld whenever you change the keys).
BIRD
----
On each router running Bird, add "authentication mac" and "key" options to
your interface definitions:
protocol babel {
interface "eth0" {
authentication mac;
key fe3c... {
algorithm hmac sha256;
};
};
}
3. Restart your network
=======================
Restart all of your Babel routers. Your routers should associate as
previously. If you run tcpdump, you should now see that all Babel packets
carry a PC and a MAC:
$ sudo tcpdump -n -i wlan0 udp
[...]
babel 2 (86) hello router-id update/prefix nh update pc | mac
4. Optional: Incremental deployment
===================================
If you need to keep your network running, you may deploy MAC protection
incrementally by temporarily running your routers in a mode in which they
sign packets but don't verify signatures. In a first step, install your
keys but tell your routers to accept unsigned packets. In babeld, say
accept-bad-signatures true
and in Bird
authentication mac permissive;
After you're satisfied that all routers have the key installed, you may
incrementally start restarting your routers with the permissive option
switched off.
5. Unimplemented: key rotation
==============================
The protocol supports a mode of operation where two keys are used on each
interface, and packets are signed by both. This is intended to support
key rotation: the new key is added to all routers, then, once this is
done, the old key is removed.
The current code in babeld doesn't support key rotation, since we haven't
been able to find a user interface that's simple and powerful enough to
handle all cases (Antonin's code did have support, but the user interface
was confusing). The current plan is to gain more experience with MAC
protection before we design a user interface for key rotation.
6. Acknowledgments
==================
The first MAC algorithm for Babel was designed and implemented by Denis
Ovsienko. The current algorithm was designed and initially implemented by
Clara Dô, Weronika Kołodziejak, and myself. The code was then extensively
massaged by Antonin Décimo. The Bird implementation is due to Toke
Høiland-Jørgensen. Also thanks to Étienne Marais and to Julien Muchembled
(the latter employed by Nexedi, who are good guys).
-- Juliusz
_______________________________________________
Babel-users mailing list
Babel-users(a)alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Hi all!
The Ninux Valsamoggia team is configuring every antenna with specific
settings like name, frequency and distance.
So we developed a new feature: the mac based configuration.
You can create a configuration file /etc/config/lime-[mac address]
containing the setting for the single antenna.
Running lime-config the configuration is read from that file (if
available), and has priority between lime-community and lime-node.
So you can compile a single firmware including multiple config files,
one for every antenna.
EG: the config file for my antenna is lime-9c417c4c8b38 and contains
setting: option hostname 'Lime-foo'
You can find the changes here:
https://github.com/itec78/lime-packages/compare/master...itec78:feature/mac…
If you want to test this feature, you can use the feed
https://github.com/itec78/lime-packages.git;feature/mac_config when
compiling.
Let me know if it can be a useful feature for the community, and if I
can create a pull request.
Bye
itec
