I own a main router, that serves several separate wireless networks. And I also own a wireless extender, connected to the main router using WDS.
However, the wireless extender can only extend one single network from the main router, as it cannot be configured as a client for several wireless network.
On a wired network, I would just trunk all networks over the same wire, using VLANs, but I do not know how to do this over wifi.
Do you have any ideas?
For a couple VLANs, using an SSID for each is functional, though can lead to "beacon pollution".
If point-to-point, establishing a link over IBSS, 802.11s, or the like, then using GRE Layer 2 tunnels also works well. I ran my devices in a star topology this way for a long time quite successfully with a significant number of VLANs. The only "issue" I had was adjusting the MTU of the underlying wireless link to over 1500 + overhead so that it wouldn't limit the system MTU at the operational level. jow recently posted some information on how to adjust the MTU of a "bare" interface.
At a high level:
gre4t- to the front of the UCI name and that you've only got 15 characters for an interface name and are going to be adding VLAN notation to the end@gtAA.NNNN for a UCI-named gretap interface called gtAA
This looks promising, I will investigate this option; many thanks!
I have been trying to set up a simple tunnel using GRE, but it always fail to forward any traffic. I read all official and external documentation, installed the gre package, all related modules, and the full version of the IP utilities, I tried with both gre and gretap, bridging and not bridging the interfaces, ... Everything looks fine, but there is no traffic at the other ed of the tunnel.
I haven't seen any relevant messages on syslog (I did not see any message at all, actually), and I am a bit lost about how to debug this; any ideas?
Here's how I vaguely remember getting it all running
Let's say that the tunnel end points are 172.16.0.100 and 172.16.0.101
First is confirming that they are reachable from each other. ping, whatever works for you.
Assuming that they are reachable, UCI configuration of the tunnel itself has a few gotchas. The most insidious is that OpenWrt "helpfully" adds gre4t- to the UCI name, so you've only got a few characters to use before you hit the 15-character Linux limit, especially if you're using VLANs
gre4t-ABCD.1234
is 15 characters long, so ABCD is the longest UCI name that I consider "safe" to use.
As I recall, I could only get the tunnels to come up if I specified both ends of them in UCI. "Trusting" routing didn't seem to work for me. My tunnel UCI looked something like
config interface 'gt01'
option proto 'gretap'
option mtu 1558
option ipaddr '172.16.0.100'
option peeraddr '172.16.0.101'
option delegate '0'
My notes indicate that is on the .100 machine -- ipaddr is "my" address, peeraddr is "their" address. Note that this assumes you've got at least 1558 MTU on the link -- enough for a 1500-byte Ethernet packet with headers and overhead, as I hopefully figured out correctly.
Make sure you're passing the GRE protocol over the interfaces in question and its not being blocked by firewalls. You should be able to see the packets with tcpdump on the underlying interfaces once they start flowing.
I don't recall being able to test things out here, though you should be able to see the tunnel interfaces with ip link or the like.
Using UCI to bridge to the tunnel portals took a lot of poking and prodding. I can't explain quite why, but here's the notation I ended up with that worked for me. Additional GRE tunnels on the same bridge also get the puzzling-to-me @ sign.
config interface 'vlan1234'
option type 'bridge'
option stp '1'
option ifname 'eth0.1234 @gt01.1234'
option proto 'none'
option auto '1'
option delegate '0'
Once that's up, you should start seeing broadcast traffic on VLAN1234, at the VLAN sub-interface of the GRE tunnel, the "main" interface of the tunnel, and encapsulated on the underlying interface (172.16.0.100/.101).
Yes, this is pretty much what I did... will have to investigate using "tcdump".
I looked through my months of notes on getting things running in Feb-April 2018 and a lot of my problems I traced to issues in the rapidly changing code base on master at the time.
I've got some cryptic notes around interface_ip_add_target_route() proto_shell_add_host_dependency() and the like from March 25th, 2018 but don't recall if I patched something in my builds, or it was eventually resolved.
back to “working” hack:
openwrt-2018-03-24-1216-g6d9356e.add-tar-ar71xx-generic-archer-c7-v2-squashfs-sysupgrade.bin
in my notes concerns me. Hmmm, this old, local commit might be "interesting", especially as it falls between when things weren't working and when I started to resolve connectivity problems under load (which turned out to be related to MTU limitations).
commit 70f36f2a848fa1e6ca51b2d6721201b489c2d03c
Date: Sat Apr 7 21:00:15 2018 -0700
Hack to remove static route for gretap target
$ git diff 70f36f2a848fa1e6ca51b2d6721201b489c2d03c^ 70f36f2a848fa1e6ca51b2d6721201b489c2d03c
diff --git a/package/network/config/gre/files/gre.sh b/package/network/config/gre/files/gre.sh
index e604bfb259..8446dc2258 100755
--- a/package/network/config/gre/files/gre.sh
+++ b/package/network/config/gre/files/gre.sh
@@ -78,6 +78,10 @@ gre_setup() {
( proto_add_host_dependency "$cfg" "$peeraddr" "$tunlink" )
+ # jmk -- hack for broken logic somewhere
+
+ ip route delete proto static "$peeraddr"
+
[ -z "$ipaddr" ] && {
local wanif="$tunlink"
if [ -z $wanif ] && ! network_find_wan wanif; then
As I vaguely recall, a "bad" route was being added that was messing things up.
Looking into that 2018-03-24 local build and what was in it.
Chacking back, I don't see any remnants of those changes from early 2018 other than the ip route delete proto static "$peeraddr" change in my late 2018 sources.
I tried to establish a simple GRE tunnel using these commands on one end (and the equivalent commands on the other end):
ip tunnel add test mode gre remote 192.168.1.254 local 192.168.1.253
ip link set test up
ip addr add 10.0.0.253/24 dev test
Everything looks right, but there is no traffic between the nodes: PINGs sent to the other end of the tunnel (10.0.0.254) do not receive any answer at all. Now I created a similar tunnel, but using IPIP instead of GRE:
ip tunnel add test2 mode ipip remote 192.168.1.254 local 192.168.1.253
ip link set test2 up
ip addr add 10.0.1.253/24 dev test2
And now at least the remote end is responding to PING requests. I still have to make the configuration permanent, create the VLANs, bridge the interfaces, ... but it looks to me that either there is a bug in the current implementation of GRE, or some issue with my tests that I cannot figure out.
Will inform later.
Well, looks line adding an "option drop_invalid '1'" line to my firewall was not such a good idea after all... after removing that line, the GRETAP tunnel finally started working; now I just have to configure the rest.
Ok, so I managed to create a tunnel for the first VLAN, and the wireless extender is now serving both the main LAN network and a secondary IoT network. So far, I am tunneling the secondary IoT network inside the main LAN network; this is not the ideal situation [*], but so far serves as a proof of concept.
On the main router, I added these lines to "/etc/config/network":
config interface 'iot'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.4.254'
option netmask '255.255.255.0'
option ipv6 '0'
config interface 'tunnel'
option proto 'gretap'
option ipaddr '192.168.1.254'
option peeraddr '192.168.1.253'
option network 'iot'
option force_link '1'
The IoT network is the one that I want to extend, and "192.168.1.0/24" is the range for the main LAN network. On the wireless extender, I added a similar interface:
config interface 'iot'
option proto 'dhcp'
option type 'bridge'
option ipv6 '0'
config interface 'tunnel'
option proto 'gretap'
option ipaddr '192.168.1.253'
option peeraddr '192.168.1.254'
option network 'iot'
option force_link '1'
This IoT network on the wireless extender gets an IP address in the "192.168.4.0/24" range, and is bridged to a wireless interface, to serve as an AP.
[*] First, because the MTU of the link maxes at 1280 bytes; and second because I need to extend several networks. To solve this, I will have to create a bare interface, and use VLANs on top of that. But that will come later. I just do not want to lose access to the wireless extender over the LAN network
This is about the best way to do it, if your link is regular AP-STA.
You can send VLANs through the tunnel simply with regular notation e.g. tunnel.2. This method means the tunnel definition must not contain an option network which would commit it to one network. Instead refer to it in each network definition.
VLAN tags do add 4 bytes to each tunneled packet which means a reduction in usable MTU.
Watch out for exceeding the 15 character limit on interface names. You would have gre4t-tunnel.2 which is 14. Use a name shorter than 'tunnel'.
The administrative link is the regular LAN which is outside the tunnel, thus mis-configuring the tunnel is not too likely to cause loss of connectivity.
Some solid advice there, thanks!
I was considering putting the administrative network as a tunnel to avoid having a low MTU on all the other networks; once everything is up and running, it should be stable enough. My main router does not support mesh, and I have never used IBSS; I am still deciding how to continue about this.
Unfortunately, I do not have many opportunities to fiddle with the network, as these are my only "production" devices.
Ok, so I managed to configure the VLANs on the tunnel; pero your advice, I changed the tunnel name, moved the bridge configuration, and changed the notation. On the main router, I have this now:
config interface 'lnk'
option proto 'gretap'
option ipaddr '192.168.1.254'
option peeraddr '192.168.1.253'
option force_link '1'
config interface 'iot'
option type 'bridge'
option proto 'static'
option ifname '@lnk.4'
option ipaddr '192.168.4.254'
option netmask '255.255.255.0'
And on the wireless extender, I have it configured as:
config interface 'lnk'
option proto 'gretap'
option ipaddr '192.168.1.253'
option peeraddr '192.168.1.254'
option force_link '1'
config interface 'iot'
option type 'bridge'
option proto 'dhcp'
option ifname '@lnk.4'
This works like a charm, I even added a second network to the link, using a different VLAN. Next step will be to use a separate network for the link with a larger MTU, so the MTU on the encapsulated networks can be raised back to 1500 bytes (it's currently at 1280 bytes).
I just realize that those interfaces do not really need an IP address on the wireless extended, as they are being used only to extend an existing auxiliary network, so I changed their prototype to "none":
config interface 'iot'
option type 'bridge'
option proto 'none'
option ifname '@lnk.4'
I also followed @jeff advice, and created a dedicated network on both devices, using a separate IP range and static addresses, and connected them both using a simple AP + STA schema; this allowed me to raise the MTU to 2KB.
Many thanks for all your help, I will mark the question as "solved" now.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.