Starting with mesh networks

stangri · March 11, 2018, 1:42pm

Do you also have authsae installed?

jeff · March 11, 2018, 3:24pm

No, I don't see it in the output of okpg list-installed

Ones I see that seem to me to be related are:

hostapd-common - 2016-12-19-ad02e79d-7
libopenssl - 1.0.2n-1
kmod-cfg80211 - 4.4.116+2017-01-31-3
kmod-mac80211 - 4.4.116+2017-01-31-3
netifd - 2017-01-25-650758b1-1
wpad-mesh - 2016-12-19-ad02e79d-7

It also runs with 17.01.4 and its packages. Those versions happen to be what is on them right now.

Edit: When I look at the authsae package, it looks like it hasn't been updated in content since 2015

commit 939175e9f253959fa3d68c1bc85cd985680183ba
Author: John Crispin <john@openwrt.org>
Date:   Tue Nov 24 18:28:35 2015 +0000

The only changes since then have been in the Makefile and the version given is

PKG_SOURCE_DATE:=2014-06-09

hostapd shows

PKG_SOURCE_DATE:=2016-12-19

stangri · March 13, 2018, 11:45am

Is libopenssl required for mesh encryption to work?

jeff · March 13, 2018, 2:09pm

Edit: Yes libopenssl gets pulled in by wpad-mesh

Package: wpad-mesh
Version: 2016-12-19-ad02e79d-7
Depends: libc, libnl-tiny, libubus, libopenssl

If you do build libopenssl into an image, you might want to set CONFIG_OPENSSL_WITH_COMPRESSION=y otherwise uhttpd won't run TLS sucessfully, at least as configured by default.

Arsham · March 19, 2018, 3:24pm

Hi

i have a setup a mesh network among 5 routers utilizing 802.11s mesh routing protocols, now i have two switches with trunk and access ports and what i am trying to do is to propagate VLAN taggs over my mesh nework (connect one mesh router to the source switch and another to the destination switch ) so as to avoid redundant mesh broadcast flow.
now the question is that are vlan taggs propagated among these routers from source switch to the destination switch using mesh routing protocol . does the mesh setup understand vlan tagging or not

That would great if anyone can guide me through this .

jeff · March 19, 2018, 4:34pm

You'll need Level 2 bridging over the 802.11s links, as VLAN tagging is a Level 2 thing. GRE is one way to handle that.

as one reference. I use a slightly different configuration, eliminating one of the Linux bridges called out there, but the concept is the same. Performance of GRE is very good with low overhead and low CPU load. https://justus.berlin/2016/02/performance-of-tunneling-methods-in-openwrt/

Arsham · March 19, 2018, 7:35pm

hey @jeff thanls for your prompt response but isn't GRE for direct tunneling communication among two routers ? The scenario which I want to implement is to use kinda multihop communication. meaning from the source to the destination many routers are engaged and frames are pass through intermmediate nodes (other 3 routers) not just direct communication

jeff · March 19, 2018, 8:42pm

Perhaps your objectives are different than mine, so let me quickly lay out what mine are:

Isolate various classes of devices from each other, and potentially limiting their outside access
Provide different services to each class of device (DNS, for example)
Wireless connectivity to most APs
Allow "seamless" roaming between multiple APs
Relatively easy to maintain, once set up

#1 I achieve through providing an SSID for each class of device, with its own subnet and VLAN
#2 I achieve by using VLAN-aware service hosts, running multiple instances, as needed
#3 I currently use 802.11s with GRE encapsulation

#4 As 802.11s, as far as I know, is effectively a routed protocol at Layer 3. The mesh is transparent to clients roaming between APs which are connected over the mesh. They aren't mesh clients, but are AP clients. While I could put every AP's clients on their own subnet and route between them, I'd need a dynamic routing protocol, which wouldn't be fast enough, especially with 802.11r. It would also mean replicating non-routable services, such as DHCP and NTP broadcast on the VLANs associated with each AP, violating #5, easy to maintain. So I chose to bridge (Layer 2) each of the VLANs among the APs and the gateway to the rest of the world rather than route them.

At a high level, my setup for each AP (including the "master" AP) looks like:

AP with distinct SSID for each class, with a VLAN constant across my entire network for that class of device
No cross-VLAN routing permitted at any AP or at the master AP
Mesh node to provide connectivity among the APs and the master AP; node-to-node self-routing provided by 802.11s
GRE tunnel over the mesh addresses, between each AP and the master AP
Each VLAN tunneled over the GRE tunnel
Ethernet connectivity between the master AP and the rest of the network (VLAN tagged)
Services provided elsewhere on VLAN-aware service hosts
Routing provided elsewhere on VLAN-aware router/firewall

Arsham · March 28, 2018, 11:38am

Here is my setup

   <laptop>----access<TP link switch1>Trunk(p5)----<buffalo router1>-----5GHZ-----<Bufallo router2>---trunk(p5)<TP link switch2>access---cisco routers(4 router each having separate vlans)

My Buffalo routers are communicating via 5GHz mesh protocol
Both switches: port 1vlan11, port2:vlan12, port3 vlan 21,port4 vlan 22 and port 5 default vlan 1(trunk)
Cisco routers: 1st router port1 , 2nd one port2, 3rd one port 3 and 4th one port 4

The thing i am trying to investigate is to find out whether the mesh protocol between 2 routers understands vlan taging . For example I can ping cisco 1 plugged to port 1 of switch2( vlan 11) form my laptop only when its connected to port 1 of the switch1 (without touching the vlaning configuration of bufallo switches ). can anyone explains if its possible?

However the laptop can only ping the first buffalo rotuer only when the ports are swapped (laptop ---> trunk port and bufallo--->access port) and can't ping in the scenario above. can anyone clarify the reason ?

thanks in advance

jeff · March 28, 2018, 2:14pm

No, it does not.

I run this same kind of setup on master builds by establishing a GRE link between each of the APs and a "master" AP (the one that has Layer 2 bridging to the wired VLANs) with the gretap sub-interfaces bridged to each VLAN, along the lines of this:

# You've only got 4 characters to use here
# gre4t-NAME.1234 has to be no more than 15 char
config interface 'gt' 
        option proto 'gretap'
        option ipaddr '172.16.0.2'
        option peeraddr '172.16.0.1'
        option force_link '1'

config interface 'mesh'
        option type 'bridge'
        option stp '1'
        option proto 'static'
        option ipaddr '172.16.0.2'
        option netmask '255.255.255.0'

# Management interface
config interface 'vlan100'
        option type 'bridge'
        option stp '1'
        option ifname 'eth1.100 @gt.100'
        option proto 'static'
        option ipaddr '10.0.1.2'
        option netmask '255.255.255.0'

# Optional; device itself on "routable" interface
# to get packages from outside world or the like
config interface 'vlan200'
        option type 'bridge'
        option stp '1'
        option ifname 'eth0.200 @gt.200'
        option proto 'static'
        option ipaddr '10.0.2.2'
        option netmask '255.255.255.0'
        
        option gateway '10.0.2.1'
        option dns '10.0.2.1'

# Trunked-only, no device interface
config interface 'vlan300'
        option type 'bridge'
        option stp '1'
        option ifname '@gt.300'
        option proto 'none'
        option auto '1'

Note that gretap with UCI config was recently fixed in master

commit d290024c42303f0017d4b556495e48c29d84626c
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Mar 27 11:32:54 2018 +0200

Arsham · March 28, 2018, 3:11pm

so in your configuration with GRE does vlaning tag going through ?

mk24 · March 28, 2018, 4:09pm

Yes the traffic through the GREtap tunnel will be tagged. You can run multiple VLANs through the same tunnel.

Another approach to this, which is common in commercial systems, is to put BATMAN-adv on top of the 802.11s radio link. VLAN tags can be applied directly to a bat interface, and it will send VLAN traffic arbitrarily throughout the mesh rather than needing pre-established point to point tunnels.

Arsham · April 4, 2018, 10:54am

Thanks for your response @mk24 and this is exactlly what i could establish lately.. with my setup explained above now the vlan taggs are being propagated via 5GHz interface between 2 Buffallo routers without having to configure p2p tunneling . meaning that mesh system can also understand vlan tagging.

However this setup only works when the laptop —> trunk port and bufallo—>access port and my laptop can no longer ping Buffalo router when the devices are swapped (laptop --> access port and Buffalo--> trunk which is what I intend to do) . any suggestions?

oavaldezi · October 23, 2018, 4:04am

I wish to set up a network with three mesh AP's, with only one of them connected to the wired network. Clients should be able to connect to any of the three mesh AP's and roam transparently using the same wireless network name (SSID?)

I've installed wpad-mesh on OpenWrt 18.06.1. I'm giving each mesh AP a unique IP address bound to their 'lan' network interfaces. Their /etc/config/wireless files are identical:

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'platform/10300000.wmac'
        option htmode 'HT20'
        option channel '6'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '_ssid name_'
        option encryption 'psk2+ccmp'
        option key '_ssid password_'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'mesh'
        option mesh_id '_mesh name_'
        option mesh_fwding '1'
        option key '_mesh password_'
        option sae_password '_mesh password_'
        option encryption 'psk2+ccmp'

The mesh comes up: I can see the other mesh APs using 'iw dev wlan0 station dump', /var/run/wpa_supplicant-wlan0.conf shows 'key_mgmt=SAE' but I can't ping or route to their IP addresses, so I believe something is fundamentally wrong with my setup.

Thanks for your comments.

jeff · October 23, 2018, 9:29am

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.

markbirss · October 23, 2018, 12:26pm

@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

oavaldezi · October 23, 2018, 12:27pm

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.

dlakelan · October 23, 2018, 3:21pm

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.

jeff · October 23, 2018, 5:42pm

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").

oavaldezi · October 23, 2018, 6:31pm

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.