search

luandro / meshpi

Scripts and image to mesh a Raspberry Pi with a Libre Mesh router
Other
24 stars 2 forks source link

Fork: https://github.com/chootka/subnodes/issues/19 #2

Open luandro opened 6 years ago

luandro commented 6 years ago

Moving original discussion on how to use subnodes scripts to mesh with Libre Mesh using BATMAN-adv.

Forked

luandro commented 6 years ago

By setting wifi'.adhoc_ssid as the MESH_SSID this is the AP the Pi is generating:

screenshot

In this case, Moinho and Moinho/teste are created by the Libre Mesh router, Palha House is some random router and LiMe is the AP the Pi created

It's strange that it lists as a device, shouldn't it be a normal network and with the same Moinho name as the routers networks?

Running batctl o still shows nothing.

luandro commented 6 years ago

MeshPi config file:

#!/bin/sh
# Config file for meshpi configuration

############################################################
############################################################
############################################################
# MESH STUFF
# FLAGS: y or n
DO_SET_MESH=y

# PARMAS FOR MESHPI_MESH INIT SCRIPT
MESH_SSID="LiMe"
MESH_CHANNEL=11
CELL_ID=ca:fe:00:c0:ff:ee
MTU=1532

# To-Do: Specify exact device you would like to use for mesh point
MESH_PHY="phy0"

############################################################
############################################################
############################################################
# IF SETTING UP A MESH NODE, CONFIGURE THE BRIDGE WHICH WILL HOLD THE MESH AND ACCESS POINTS
# START WITH NUMBER 2+ (UNLESS THIS IS A GATEWAY NODE, THEN USE .1)
BRIDGE_IP=10.168.100.2
BRIDGE_NETMASK=255.255.255.0

############################################################
############################################################
############################################################
# HOSTAPD STUFF
# WIRELESS RADIO DRIVER
RADIO_DRIVER=nl80211

# ACCESS POINT
AP_COUNTRY=US

# BE SURE TO USE A UNIQUE NAME
AP_SSID="meshpi$((RANDOM%10000+1))"

# Recommended channels: 1, 6 or 11. Do not use channels 12 or 13 because they won't work with the onboard RPi3 radio
AP_CHAN=6

# START WITH NUMBER 2+ (UNLESS THIS IS A GATEWAY NODE, THEN USE .1)
AP_IP=10.80.100.2
AP_NETMASK=255.255.255.0

# To-Do: Specify exact device you would like to use for access point
#AP_PHY="phy1"

############################################################
############################################################
############################################################
# DNSMASQ STUFF

# SET THE DHCP NETMASK AND LEASE ( do not change unless you know what you're doing :) )
DHCP_NETMASK=255.255.255.0
DHCP_LEASE=1h

# IF WE ARE ONLY SETTING UP AN ACCESS POINT
# SET THE DHCP RANGE
AP_DHCP_START=10.80.100.101
AP_DHCP_END=10.80.100.254

# IF WE ARE SETTING UP A MESH AND ACCESS POINT
# SET THE DHCP RANGE
BR_DHCP_START=10.168.100.101
BR_DHCP_END=10.168.100.254

############################################################
############################################################
############################################################
# other options could be
#  - Other Adapter Names
# ....

/etc/config/lime config file:

config lime 'system'
    option domain 'lan'
    option hostname 'teste'

config lime 'network'
    list protocols 'ieee80211s'
    list protocols 'lan'
    list protocols 'anygw'
    list protocols 'batadv:%N1'
    list protocols 'bmx6:13'
    list protocols 'olsr:14'
    list protocols 'olsr6:15'
    list protocols 'olsr2:16'
    option primary_interface 'eth0'
    list resolvers '4.2.2.2'
    list resolvers '141.1.1.1'
    list resolvers '2001:470:20::2'
    option main_ipv4_address '10.%N1.0.0/16'
    option main_ipv6_address '2a00:1508:0a%N1:%N200::/64'
    option anygw_mac 'aa:aa:aa:%N1:%N2:aa'
    option anygw_dhcp_start '2'
    option anygw_dhcp_limit '0'
    option bmx6_over_batman 'false'
    option bmx6_mtu '1500'
    option bmx6_pref_gw 'none'

config lime 'wifi'
    list modes 'ap'
    list modes 'apname'
    list modes 'ieee80211s'
    option ieee80211s_mesh_id 'LiMe'
    option adhoc_mcast_rate_5ghz '6000'
    option distance '1000'
    option ieee80211s_mesh_fwding '0'
    option apname_ssid 'Moinho/%H'
    option adhoc_bssid 'ca:fe:00:c0:ff:ee'
    option htmode_5ghz 'HT40'
    option channel_2ghz '11'
    option adhoc_mcast_rate_2ghz '24000'
    option channel_5ghz '48'
    option adhoc_ssid 'LiMe'
    option ap_ssid 'Moinho'

config net 'lm_hwd_openwrt_wan'
    option autogenerated 'true'
    list protocols 'ieee80211s'
    list protocols 'anygw'
    list protocols 'batadv:%N1'
    list protocols 'bmx6:0'
    list protocols 'olsr:14'
    list protocols 'olsr6:15'
    list protocols 'olsr2:16'
    list protocols 'wan'
    option linux_name 'eth0.2'
MaStr commented 6 years ago

I think the easiest way is to try out some WiFi snooping software like kismet to actually see the exact details of the stuff working in channel 11

On 31. Mar 2018, at 17:17, Luandro notifications@github.com wrote:

MeshPi config file:

!/bin/sh

Config file for meshpi configuration

############################################################ ############################################################ ############################################################

MESH STUFF

FLAGS: y or n

DO_SET_MESH=y

PARMAS FOR MESHPI_MESH INIT SCRIPT

MESH_SSID="LiMe" MESH_CHANNEL=11 CELL_ID=ca:fe:00:c0:ff:ee MTU=1532

To-Do: Specify exact device you would like to use for mesh point

MESH_PHY="phy0"

############################################################ ############################################################ ############################################################

IF SETTING UP A MESH NODE, CONFIGURE THE BRIDGE WHICH WILL HOLD THE MESH AND ACCESS POINTS

START WITH NUMBER 2+ (UNLESS THIS IS A GATEWAY NODE, THEN USE .1)

BRIDGE_IP=10.168.100.2 BRIDGE_NETMASK=255.255.255.0

############################################################ ############################################################ ############################################################

HOSTAPD STUFF

WIRELESS RADIO DRIVER

RADIO_DRIVER=nl80211

ACCESS POINT

AP_COUNTRY=US

BE SURE TO USE A UNIQUE NAME

AP_SSID="meshpi$((RANDOM%10000+1))"

Recommended channels: 1, 6 or 11. Do not use channels 12 or 13 because they won't work with the onboard RPi3 radio

AP_CHAN=6

START WITH NUMBER 2+ (UNLESS THIS IS A GATEWAY NODE, THEN USE .1)

AP_IP=10.80.100.2 AP_NETMASK=255.255.255.0

To-Do: Specify exact device you would like to use for access point

AP_PHY="phy1"

############################################################ ############################################################ ############################################################

DNSMASQ STUFF

SET THE DHCP NETMASK AND LEASE ( do not change unless you know what you're doing :) )

DHCP_NETMASK=255.255.255.0 DHCP_LEASE=1h

IF WE ARE ONLY SETTING UP AN ACCESS POINT

SET THE DHCP RANGE

AP_DHCP_START=10.80.100.101 AP_DHCP_END=10.80.100.254

IF WE ARE SETTING UP A MESH AND ACCESS POINT

SET THE DHCP RANGE

BR_DHCP_START=10.168.100.101 BR_DHCP_END=10.168.100.254

############################################################ ############################################################ ############################################################

other options could be

- Other Adapter Names

....

/etc/config/lime config file:

config lime 'system' option domain 'lan' option hostname 'teste'

config lime 'network' list protocols 'ieee80211s' list protocols 'lan' list protocols 'anygw' list protocols 'batadv:%N1' list protocols 'bmx6:13' list protocols 'olsr:14' list protocols 'olsr6:15' list protocols 'olsr2:16' option primary_interface 'eth0' list resolvers '4.2.2.2' list resolvers '141.1.1.1' list resolvers '2001:470:20::2' option main_ipv4_address '10.%N1.0.0/16' option main_ipv6_address '2a00:1508:0a%N1:%N200::/64' option anygw_mac 'aa:aa:aa:%N1:%N2:aa' option anygw_dhcp_start '2' option anygw_dhcp_limit '0' option bmx6_over_batman 'false' option bmx6_mtu '1500' option bmx6_pref_gw 'none'

config lime 'wifi' list modes 'ap' list modes 'apname' list modes 'ieee80211s' option ieee80211s_mesh_id 'LiMe' option adhoc_mcast_rate_5ghz '6000' option distance '1000' option ieee80211s_mesh_fwding '0' option apname_ssid 'Moinho/%H' option adhoc_bssid 'ca:fe:00:c0:ff:ee' option htmode_5ghz 'HT40' option channel_2ghz '11' option adhoc_mcast_rate_2ghz '24000' option channel_5ghz '48' option adhoc_ssid 'LiMe' option ap_ssid 'Moinho'

config net 'lm_hwd_openwrt_wan' option autogenerated 'true' list protocols 'ieee80211s' list protocols 'anygw' list protocols 'batadv:%N1' list protocols 'bmx6:0' list protocols 'olsr:14' list protocols 'olsr6:15' list protocols 'olsr2:16' list protocols 'wan' option linux_name 'eth0.2' — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

MaStr commented 6 years ago

And you should verify with the same commands on the OpenWrt / libremesh router if THAT device is acutally up and running.

How did you create the libremesh image? Is there a vanilla image, which you flash and then configure? Or is that more like an image-creation tool? Is there a way I can prepare that setup on my side as well?

luandro commented 6 years ago

It's a firmware that you install and it's ready to mesh, based on OpenWRT. Just download it from here and flash a compatible router.

Running on the LibreMesh router:

Running on the Pi:

I'll get Kismet installed on my computer.

luandro commented 6 years ago

Kismet information for channel 11:

screenshot

Is Wi-Fi Adhoc right for the Pi AP?

MaStr commented 6 years ago

To be clear. Pi AccessPoint is running on a different channel (according to what I found). The Pi Mesh Interface should be WiFi Adhoc.

I'm tidying up my desk now and then I'll start to replicate that setup. Maybe there is something else wrong. (btw: i have my own BATMAN-adv starter script ;-).. I'll start there after LibreMesh is up )

MaStr commented 6 years ago

Ok, I think I am coming closer to the issue.

This is my libreMesh node:

root@LiMe-402ed0:~# iw dev 
phy#0
    Interface wlan0-apname
        ifindex 14
        wdev 0x4
        addr e2:95:6e:40:2e:d0
        ssid LibreMesh.org/LiMe-402ed0
        type AP
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 18.00 dBm
    Interface wlan0-ap
        ifindex 13
        wdev 0x3
        addr e6:95:6e:40:2e:d0
        ssid LibreMesh.org
        type AP
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 18.00 dBm
    Interface wlan0-mesh
        ifindex 11
        wdev 0x2
        addr e4:95:6e:40:2e:d0
        type mesh point
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 18.00 dBm
root@LiMe-402ed0:~# batctl if
dummy0: active
wlan0-mesh_29: active

So Important is that line

type mesh point

Type meshpoint is the new 802.11s mesh mode of wifi cards. Subnodes and my script is using the very old AdHoc mode (which is more compatible in some cases).

I am digging further

MaStr commented 6 years ago

I figured out the steps to get an 802.11s interface up and running, but for some reason the both devices do not mesh with each other. It seems they can't find the other, while on kismet I can see both mac addresses broadcasting. I am searching for troubleshooting hints now...

edit: just to emphasize it: The issue, how I observe it, is not a BATMAN-adv issue, but it is an 802.11s configuration (or device?) issue. In fact, batman-adv is working on a layer above, so the first step is to make sure, that the wifi-mesh link is working.

@luandro Can you run the following command on your LibreMesh device:

iw dev
iw wlan0-mesh_201 station dump
iw wlan1-mesh_201 station dump
luandro commented 6 years ago

You're awesome. That's really strange, wish I could help with anything, but I'm such a noob =(

MaStr commented 6 years ago

I just updated my post above (sorry, forgot refreshing). can you post the output of the commands on your libremesh router?

luandro commented 6 years ago

iw dev:

root@teste:~# iw dev
phy#1
    Interface wlan1-apname
        ifindex 18
        wdev 0x100000004
        addr a6:f3:c1:bf:98:68
        ssid Moinho/teste
        type AP
        channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz
        txpower 15.00 dBm
    Interface wlan1-ap
        ifindex 16
        wdev 0x100000003
        addr a2:f3:c1:bf:98:68
        ssid Moinho
        type AP
        channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz
        txpower 15.00 dBm
    Interface wlan1-mesh
        ifindex 13
        wdev 0x100000002
        addr a0:f3:c1:bf:98:68
        type mesh point
        channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz
        txpower 15.00 dBm
phy#0
    Interface wlan0-apname
        ifindex 19
        wdev 0x4
        addr a6:f3:c1:bf:98:67
        ssid Moinho/teste
        type AP
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 20.00 dBm
    Interface wlan0-ap
        ifindex 17
        wdev 0x3
        addr a2:f3:c1:bf:98:67
        ssid Moinho
        type AP
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 20.00 dBm
    Interface wlan0-mesh
        ifindex 15
        wdev 0x2
        addr a0:f3:c1:bf:98:67
        type mesh point
        channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
        txpower 20.00 dBm

The other two station dump commands have no output.

MaStr commented 6 years ago

Ok, can you give me similar output from the Pi? Then I create a series of commands, to setup that 802.11s thingy manually (just to test if the connectivity works in your case)

luandro commented 6 years ago 
pi@meshpi:~ $ iw dev
phy#1
    Interface wlan1
        ifindex 5
        wdev 0x100000001
        addr 10:fe:ed:1b:3f:ed
        ssid LiMe
        type IBSS
        channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
        txpower 20.00 dBm
phy#0
    Interface wlan0
        ifindex 3
        wdev 0x1
        addr b8:27:eb:f6:e0:8c
        type managed
        channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
        txpower 31.00 dBm

When I try the station dump commands it prints the -h is if the command didn't work.

MaStr commented 6 years ago

yes, that confirms, that there is the "setup" missmatch between the Pi and the LibreMesh. LibreMesh uses 802.11s and your Pi (subnode) script does the legacy AdHoc mode.

iw only gives you a help output with just "iw"

run

iw wlan1 del
iw phy1 interface add mesh0 type mesh
ifconfig mesh0 mtu 1528
iwconfig mesh0 channel 11
ifconfig mesh0 up
iw dev mesh0 mesh join LiMe

after this double check again with "iw mesh0 station dump" and corresponding on the libremesh router. These steps do not add the new device "mesh0" to the batman-adv stuff.. but we have to start somewhere.

I also did some wifi monitoring dump and analyze the wifi packages... trying to get an idea what is wrong. (Yes, I am sitting here with my notebooks internal wifi card, an wifi usb adapter for meshing, one running monitor mode for analyzing and the glinet device :-)

Have to run off for today, tomorrow I won't have much time. As soon as I can, I will get back to the topic.

luandro commented 6 years ago

After running the commands on the Pi I get:

pi@meshpi:~ $ sudo iw mesh0 station dump
Station a0:f3:c1:bf:98:67 (on mesh0)
    inactive time:  0 ms
    rx bytes:   18597
    rx packets: 263
    tx bytes:   166
    tx packets: 3
    tx retries: 0
    tx failed:  0
    rx drop misc:   0
    signal:     -13 [-13] dBm
    signal avg: -13 [-13] dBm
    Toffset:    24521418505 us
    tx bitrate: 39.0 MBit/s MCS 4
    rx bitrate: 24.0 MBit/s
    mesh llid:  52609
    mesh plid:  49716
    mesh plink: ESTAB
    mesh local PS mode: ACTIVE
    mesh peer PS mode:  ACTIVE
    mesh non-peer PS mode:  ACTIVE
    authorized: yes
    authenticated:  yes
    associated: yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    DTIM period:    2
    beacon interval:1000
    short slot time:yes
    connected time: 11 seconds

You've been amazing, I really appreciate your patience. I'll try messing around with it some more, hope you can get some time again soon. Cheers!

MaStr commented 6 years ago

Woot! I am jealous! My setup just won’t work. Ok, well then the next steps are adjusting the subnode script

On 31. Mar 2018, at 22:20, Luandro notifications@github.com wrote:

After running the commands on the Pi I get:

pi@meshpi:~ $ sudo iw mesh0 station dump Station a0:f3:c1:bf:98:67 (on mesh0) inactive time: 0 ms rx bytes: 18597 rx packets: 263 tx bytes: 166 tx packets: 3 tx retries: 0 tx failed: 0 rx drop misc: 0 signal: -13 [-13] dBm signal avg: -13 [-13] dBm Toffset: 24521418505 us tx bitrate: 39.0 MBit/s MCS 4 rx bitrate: 24.0 MBit/s mesh llid: 52609 mesh plid: 49716 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes associated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no DTIM period: 2 beacon interval:1000 short slot time:yes connected time: 11 seconds You've been amazing, I really appreciate your patience. I'll try messing around with it some more, hope you can get some time again soon. Cheers!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

MaStr commented 6 years ago

ok, it seems that all three of my USB wifi adapters are not able to run in 802.11s mode. They accept all commands and everything is setup correctly. The wifi packet dump shows up beacons, but it seems all cards are not able to associate with the glinet :-(

After you got it on the Pi working, can you give me a full output from 

iw list

Just to confirm you have 

         * mesh point
         * P2P-client
         * P2P-GO

under "Supported interface modes:"

Can you name me the wifi adapter you are using?

Ok, beside of that hiccup on my side, it seems we need to improve the mesh-setup script. Correct? Or can you do it by yourself with adjusting the commands? I'm just asking to avoid duplicate work.

best regards Matthias

luandro commented 6 years ago

Hey Matthias, I'm using a TP-LINK_TL-WN722N version 1.2, which has Atheros chipset. Took me two other wrong buys before finally getting the right chipset. Yes I got all three:

* mesh point
* P2P-client
* P2P-GO

Here's the full output:

pi@meshpi:~ $ iw list
Wiphy phy1
    max # scan SSIDs: 4
    max scan IEs length: 2257 bytes
    max # sched scan SSIDs: 0
    max # match sets: 0
    max # scan plans: 1
    max scan plan interval: -1
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports RSN-IBSS.
    Device supports T-DLS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
        * CCMP-256 (00-0f-ac:10)
        * GCMP-128 (00-0f-ac:8)
        * GCMP-256 (00-0f-ac:9)
        * CMAC (00-0f-ac:6)
        * CMAC-256 (00-0f-ac:13)
        * GMAC-128 (00-0f-ac:11)
        * GMAC-256 (00-0f-ac:12)
    Available Antennas: TX 0x1 RX 0x1
    Configured Antennas: TX 0x1 RX 0x1
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * AP/VLAN
         * monitor
         * mesh point
         * P2P-client
         * P2P-GO
         * outside context of a BSS
    Band 1:
        Capabilities: 0x116e
            HT20/HT40
            SM Power Save disabled
            RX HT20 SGI
            RX HT40 SGI
            RX STBC 1-stream
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 8 usec (0x06)
        HT TX/RX MCS rate indexes supported: 0-7
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps (short preamble supported)
            * 5.5 Mbps (short preamble supported)
            * 11.0 Mbps (short preamble supported)
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (20.0 dBm)
            * 2472 MHz [13] (20.0 dBm)
            * 2484 MHz [14] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * new_station
         * new_mpath
         * set_mesh_config
         * set_bss
         * authenticate
         * associate
         * deauthenticate
         * disassociate
         * join_ibss
         * join_mesh
         * remain_on_channel
         * set_tx_bitrate_mask
         * frame
         * frame_wait_cancel
         * set_wiphy_netns
         * set_channel
         * set_wds_peer
         * tdls_mgmt
         * tdls_oper
         * probe_client
         * set_noack_map
         * register_beacons
         * start_p2p_device
         * set_mcast_rate
         * channel_switch
         * set_qos_map
         * connect
         * disconnect
    Supported TX frame types:
         * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * IBSS: 0x40 0xb0 0xc0 0xd0
         * managed: 0x40 0xd0
         * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * mesh point: 0xb0 0xc0 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
         * AP/VLAN
         * monitor
    valid interface combinations:
         * #{ managed, P2P-client } <= 2, #{ AP, mesh point, P2P-GO } <= 2,
           total <= 2, #channels <= 1
    HT Capability overrides:
         * MCS: ff ff ff ff ff ff ff ff ff ff
         * maximum A-MSDU length
         * supported channel width
         * short GI for 40 MHz
         * max A-MPDU length exponent
         * min MPDU start spacing
    Device supports TX status socket option.
    Device supports HT-IBSS.
    Device supports SAE with AUTHENTICATE command
    Device supports low priority scan.
    Device supports scan flush.
    Device supports AP scan.
    Device supports per-vif TX power setting
    Driver supports full state transitions for AP/GO clients
    Driver supports a userspace MPM
    Device supports configuring vdev MAC-addr on create.
Wiphy phy0
    max # scan SSIDs: 10
    max scan IEs length: 2048 bytes
    max # sched scan SSIDs: 16
    max # match sets: 16
    max # scan plans: 1
    max scan plan interval: -1
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports T-DLS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * P2P-client
         * P2P-GO
         * P2P-device
    Band 1:
        Capabilities: 0x1020
            HT20
            Static SM Power Save
            RX HT20 SGI
            No RX STBC
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT TX/RX MCS rate indexes supported: 0-7
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps (short preamble supported)
            * 5.5 Mbps (short preamble supported)
            * 11.0 Mbps (short preamble supported)
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (20.0 dBm)
            * 2472 MHz [13] (20.0 dBm)
            * 2484 MHz [14] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * join_ibss
         * set_pmksa
         * del_pmksa
         * flush_pmksa
         * remain_on_channel
         * frame
         * set_channel
         * tdls_oper
         * start_sched_scan
         * start_p2p_device
         * crit_protocol_start
         * crit_protocol_stop
         * connect
         * disconnect
    Supported TX frame types:
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * managed: 0x40 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
    valid interface combinations:
         * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
           total <= 3, #channels <= 1
         * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
           total <= 4, #channels <= 1
    Device supports scan flush.

Yes you are correct about the mesh-setup script, but unfortunately I wouldn't even know where to start. It would be comforting if you could send some PRs so I could first learn a bit from them, and hopefully be able to help as well.

MaStr commented 6 years ago

Thanks for posting, I am reviewing my WN722N now... I can't get it working on my side, incredible!

Ok, I'll have a look what is needed to be changed.

MaStr commented 6 years ago

Stupid side question: Why do you want to have the Pi as a full mesh client and not only like a normal client connected to a running AP ? Would be much easier, wouldn't it?

luandro commented 6 years ago

Not stupid.

I was thinking it would be good to have Pis as gateway nodes, tunneling access to broadband thru a VPN. Also as smart nodes, gathering SSB information from the network and aggregating with Dat.

Now that you mention it I'm not sure they would have to necessarily be a mesh node in order to play those parts.

But than again, it would be nice to use the Pi as a mesh node, so that we don't need to have a Pi and a router in some houses on the mesh.

What do you think?

MaStr commented 6 years ago

I don't see a big advantage in using the RPi only as a mesh node OVER connecting the PI (via ethernet) to a LibreMesh router. On the LibreMesh router you have additional service you need to port to RPi itself, to make it a fully working Node. These things are like network services like Alfred or other network management function which are coming with the LibreMesh image file. The next step, which he haven't discussed yet, is the IPv4 and IPv6 configuration. You have to duplicate the implentation of IPv4 generation and IPv6 gathering for being a direct node participant, which as a client, you can just consume the LibreMesh function.

In addition you will always have the trouble to make sure your users are having a correct & supported wifi adapter.

I do not know which kind of VPN LibreMesh supports or uses. On the Freifunk images, there is a special VPN software which just forwards the traffic to an VPN-Internet-Gateway. This traffic is not encrypted, only encapsulated. Only when you have *a lot of traffic through the Internet-Connected node you run into a CPU bottleneck. In this case, the Freifunk guys in Wiesbaden are running special "offloader" which are PC hardware and customized software together with customized nodes.

A RPi connected to a LibreMesh node can also broadcasts its messages like being directly part of the Mesh.

That were my first & second thoughts about that approach, what do you think?

luandro commented 6 years ago

That actually makes a lot of sense and makes things a lot easier. Use each hardware for what it's good at. Routers for spreading the network and Pis for doing the heavy CPU work. Is that it?

I don't have another Libre Mesh router to test it out, but in theory would all the devices in the network show up as local peers in SSB and Dat?

My first plans for the Pi would be to run a NodeJS captive portal, and to run some other services such as youtube-dl as a local backend for some applications which will run on the mesh. It makes sense using the Pi that way right?

The big problem now would be a way for neighbors to share broadband, which I was planning on solving with VPNs, but it seems guys from libremesh are thinking on something better with pitbull. The use case is that people can get together and share an expensive satellite ISP. So we would need a system where users can control which devices/users are granted access.

MaStr commented 6 years ago

I guess, in SSB you won't see particular network devices, ony ssb related devices. SSB is just another layer (application layer), while mesh networking is running on LinkLayer etc. ( OSI Layer ).

You do not necessarily run a captive portal to provide local content. Depending on the infrastructure of LibreMesh you can use a domain including subdomains to provide an relatively easy access. It sounds, that your network relies on people talking together. So, it can be useful to have a wiki or something as a "home"page which points to other subdomains or hostnames providing certain services. Beyond a certain point, doing organization & documentation of the infrastructure might be necessarily as well...

I ran a PirateBox inside the Wiesbaden Freifunk network, which was only accessible via Freifunk's wifi (interconnected between offset through VPN tunnels).

I am not a fan of restricting the internet access, because it causes trouble for devices which can not register at the captive portal.

luandro commented 6 years ago

I've played around with PirateBox about a year ago, was one of my first inspirations. Unfortunately we have to restrict internet access since bandwidth is such a scarce resource here, and we need people to pay their share to use it, else they can freely use local content.

Moinho is a place which receives lots of tourists due to it's waterfalls, but the community benefits very little from this. The captive portal would serve a map for the tourists to see what cultural attractions exist in the village. Do you have any good resources for creating a captive portal?

Using dnsmasq to mock domains is a good idea for applications, although I plan to have all applications running on a decentralized protocol such as SSB.

So with that conclusion I guess we can basically wrap up the mesh part, right? Use Libre Mesh routers for spreading the mesh, and Pis connected to them thru ethernet to provide extra services to the network.

MaStr commented 6 years ago

dnsmasq is one option for the domains. You can also use a normal domain on a VPS with a dns server and just use normal DNS lookups. For example you own: moinho.net central.moinho.net => 10.10.1.2 (landing page) ssb-pub1.moinho.net => 10.10.2.35 .. You are able to use things like mumble (free teamspeak) across the mesh network.. SIP servers etc.

The problem is, you may need control over all dns requests (and maybe all running dnsmasq?!) across your libremesh network.

The captive portal is a tough thing! You have to think outside one particular router, because you can not control, if a user moves between two APs (with the same SSID). In case of router-centric approach: If she moves from one AP to another, the device needs to re-auth against the captive portal at the new AP.

The PirateBox appoach (faking dns-answers) won't help you as well.

So, the best thing is: ask the libremesh guys, maybe these have an idea about that. I only know about one-device solutions and nothing would work in a flat hierarchic network. (Keep in mind: If you use a captive portal on the internet gateways only, these gateways may need to allow each of the single routers, too. ?!)

PS: in the case you haven't noticed: I'm Matthias from the PirateBox forum and @MaStr at SSB

luandro commented 6 years ago

Man, that's a lot to think about when dealing with captive portals. I'll be traveling to visit some Libre Mesh communities in Argentina in the upcoming weeks. I'll see how they approach these problems.

Can't seem to find you in SSB, can you try following me? For me it's the best place to communicate (despite the occasional bug).

MaStr commented 6 years ago

I don’t want to play the bad guy in that discussion, but I think it is fair to mention concerns and keep discussing instead of wait and see.

Maybe the solution is less difficult then we both think, like a central VPN dealing . And the needed connectivity for routers can be solved with pseudo internal services (Like a local NTP Server)

I’m still struggling with ssb-patchwork , but your posts already look quite nice. I’m following you since a day or two.

On 2. Apr 2018, at 22:36, Luandro notifications@github.com wrote:

Man, that's a lot to think about when dealing with captive portals. I'll be traveling to visit some Libre Mesh communities in Argentina in the upcoming weeks. I'll see how they approach these problems.

Can't seem to find you in SSB, can you try following me? For me it's the best place to communicate (despite the occasional bug).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

luandro commented 6 years ago

That's weird, no user with name @MaStr shows up in SSB.

It's very important to think about the problems beforehand, wish I could to that. But I'm such a noob in networking that I can't think that way yet. Anyways, guess the next step is to get another Libre Mesh node to test things up. Let me know if you come up with any ideas. Can't thank you enough for your time and effort 👍

MaStr commented 6 years ago

The long ID is: @5JKV2nKE7XetgZXQP2Unq3eG/4J9w0JaFJ8CeXyKycw=.ed25519

Just keep on learning and playing around. I admit, that the mesh topic was difficult, because there are two kind of implementations around- and even myself can't fix my local issues :-1:
Try to get your head around IPv4 (IP addresses, networking, sockets, nameresolution (and hierarchy of name resolution). Try to use some tools to look at what is going on and never stop playing. If you understand the fundermentals, it is getting easier and easier to make progress in network topics. I read you posts on SSB and I can say, you are sounding much motivated! You have a vision, and the energy to go forward. Keep going!