802.11s routing is, as far as I know, is only for 802.11s mesh nodes. The APs' clients are off-mesh, and won't be routed. Once you get to that point, you'll either need to tunnel or route client traffic over the mesh, or use something like https://openwrt.org/docs/guide-user/network/wifi/mesh/batman instead of the 802.11s routing protocols.
That link should also help you getting your mesh up and running. Without seeing your /etc/config/network, I'm guessing that the problem lies there.
@oavaldezi im not sure but maybe that encryption combination is not supported ?
option encryption 'psk2+ccmp'
Refer to this OLSR guide with aes encryption
https://justingoetz.net/docs/docs_openwrt/olsr/adhoc-wpa.html
Im also using wpad-mesh with 18.06.1 version, the guide above changes slightly with newer luci interface with regard to the mesh network interface creation
Thank you @jeff for your reply. The mesh APs' /etc/config/wireless only differ in their lan ip addresses and their MACs:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix '_unique local address_'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.0.101'
option netmask '255.255.255.0'
option gateway '192.168.0.1'
list dns '200.12.232.4'
list dns '200.12.229.1'
list dns '8.8.8.8'
option ip6assign '60'
config device 'lan_dev'
option name 'eth0.1'
option macaddr '_mac address_'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_dev'
option name 'eth0.2'
option macaddr '_other mac address_'
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6t'
Should my setup be sufficient for clients to roam from mesh AP to mesh AP while using the same wireless network name? Will the clients associated to a non-wired mesh AP be able to connect through to the wired mesh AP?
Since two of the mesh APs won't be wired, I would have liked to log in to them from the clients for administration. That's why I'm concerned about not being able to route to them.
Any N access points that share a backhaul and have the same SSID and the same security, and are on separate channels will be sufficient to roam successfully. Whether the backhaul is mesh, ethernet, powerline, or something exotic (fiber, coax, whatever) doesn't matter.
What the mesh backhaul gives you is zero wires and the ability to move the APs around easily to optimize placement.
That's what I've got up and running at home. In my case, three or four of the five are "wireless only" with administrative access via a dedicated VLAN carried over the mesh, just as each of the isolated SSIDs have their own VLANs. I was originally using GRE, Layer 2 tunnels, but have moved to batman-adv as the configuration is easier (no "master" AP that is configured differently than the "remotes").
Thank you for your reply @dlakelan. Each mesh AP has to be on a separate channel? What would happen if they were on the same channel? I'm currently using WDS, and I have them on the same channel, but roaming is nonexistent.
Thank you for your reply @jeff. Would you share your batman-adv config files and installation procedure?
See the batman-adv wiki link above for my config. Apologies for brevity, but on my phone and wanted to get you going before my day ended.
Meshes need to be on the same channel to talk to each other, but the regular AP (which is a separate SSID) is better off on different channels. One way to accomplish this is if you use dual radio APs and put the mesh on a separate radio from the access point for clients.
Roaming is entirely controlled by the client. The ESSID identifies radios that all participate in the same network (ESSID stands for Extended Service Set ID, meaning a network of radios that all are connected to the same subnet). The client determines which of those radios to talk to based on its own decision making software.
The best way to force clients to roam is turn down power on the radio so that it loses its signal around about the time the closer AP has a very good signal. There are some hacks to hostapd to force clients off based on received signal strength (received by the hostapd AP) but they are not yet integrated in OpenWRT that I know of. Ideally you have at most two radios (on different changes) with usable signal strength at any point in the physical space you are covering. Wherever you are, the closest and maybe second closest APs could be usable, but all other APs should be turned down enough that they are unusable (ie. -85 dBm received strength or less).
If you have that situation, you will get roaming.
My mesh is working! But I haven't configured any security options for the mesh interface yet:
config wifi-iface
option device 'radio0'
option ifname 'mesh0'
option network 'lan'
option mode 'mesh'
option mesh_id 'meshID'
option mesh_fwding '1'
According to this article published in IEEE Wireless Communications,
"With 802.11s, mesh stations perform the dictionary attack-proof Simultaneous Authentication of Equals (SAE) [11] algorithm. Besides mutual authentication, SAE provides two mesh stations with a pairwise master key (PMK) that they use to encrypt their frame. As its name indicates, SAE does not rely on a keying hierarchy like traditional 802.11 encryption [4]. Instead, it implements a distributed approach that both mesh stations may initiate simultaneously. Because of the pairwise encryption, each link is independently secured."
So, could it be that mesh stations do their own authentication, and no explicit security settings need to be configured in /etc/config/wireless ?
No magic -- if you don't configure the security settings, it will be an unencrypted mesh. With SAE they still need some kind of "shared secret". The common configuration is "trivial" by adding
option encryption 'psk2+ccmp'
option sae_password '<your secure pass phrase goes here>'
(or key instead of sae_password) to the stanza.
@oavaldezi this might be of interest to you, a script for 802.11s/adhoc mesh from freifunk
https://jenkins.kbu.freifunk.net/files/node-config/doc/
Dump some network traffic with tcpdump and check for plaintext eg
tcpdump -A -i wlan0-mesh
tcpdump -D
1.eth0 [Up, Running]
2.dummy0 [Up, Running]
3.br-lan [Up, Running]
4.anygw [Up, Running]
5.bat0 [Up, Running]
6.wlan0-mesh [Up, Running]
7.wlan1-mesh [Up, Running]
8.bmxmain [Up, Running]
9.wlan0-ap [Up, Running]
10.wlan1-ap [Up, Running]
11.wlan1-apname [Up, Running]
12.wlan0-apname [Up, Running]
13.bmxC4main [Up, Running]
14.bmxC6main [Up, Running]
15.wlan1-mesh_13 [Up, Running]
16.wlan0-mesh_13 [Up, Running]
17.wlan1-mesh_29 [Up, Running]
18.wlan0-mesh_29 [Up, Running]
19.bmxOut_LiMe-68 [Up, Running]
20.any (Pseudo-device that captures on all interfaces) [Up, Running]
21.lo [Up, Running, Loopback]
22.eth1 [Up]
23.eth1_29 [Up]
on tcpdump or wireshark running on a monitor interface
Logs are a good place to look as well, though I like an "independent" source of information as well.
Also, apps like Wifi Analyzer (at least on Android) will show encryption being advertised / required for a quick check.
My 802.11s mesh is working, except for encryption. I'll continue my questions about encryption in this other, more appropriate thread .
For reference, these are my current OpenWrt 18.06.1 config files, which bring up a working (although unencrypted) 802.11s mesh:
/etc/config/network:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix '<redacted>'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.0.2'
option netmask '255.255.255.0'
option gateway '192.168.0.1'
list dns '200.12.232.4'
list dns '200.12.229.1'
list dns '8.8.8.8'
option ip6assign '60'
config device 'lan_dev'
option name 'eth0.1'
option macaddr '<redacted>'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_dev'
option name 'eth0.2'
option macaddr '<redacted>'
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6t'
/etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10300000.wmac'
option htmode 'HT20'
option disabled '0'
option legacy_rates '1'
option channel '1'
config wifi-iface
option device 'radio0'
option ifname 'wlan0'
option network 'lan'
option mode 'ap'
option ssid '<redacted>'
option encryption 'psk2+ccmp'
option key '<redacted>'
config wifi-iface
option device 'radio0'
option ifname 'mesh0'
option network 'lan'
option mode 'mesh'
option mesh_id '<redacted>'
option mesh_fwding '1'
@jeff the last libremesh firmwares i used also result in a 802.11s mesh with no encryption. (if you build the default firmware)
but does offer network profiles
the beta chef web builder and chef builder does offer network profiles for encrypted 802.11s configuration and firmware
https://chef.libremesh.org/
https://as-test.stephen304.com/chef/
give the chef builder with a 802.11 encrypted profile a try
OR
https://justingoetz.net/docs/docs_openwrt/olsr/adhoc-wpa.html
however the olsr guide i posted before above can be configured with encryption with a adhoc (olsr) mesh - working on OpenWRT 18.06.1
Can not find the package libremesh-encrypt-11s.
i did build for my device a firmware on chef with but it still had issues to ping the other device
sign up for the mailing list to seek more help and report issues