GL-B1300 - DHCP / Routing problems with Guest WiFi in Mesh

Technical Support for Routers
1

Hey guys,

I am running two GL-B1300 (Convexa B), the first one as Mesh Master Node and the second one as Mesh Sub-Node. The connection inbetween is wired Ethernet backhaul. I have two WiFi networks running, the main (personal) wifi @5G and the guest wifi @2G and 5G. Both of them running fine on the master node, the main wifi running fine on the mesh sub node. However, there is a problem with the guest network on the mesh sub node.

For better unterstanding:

GL-B1300 1 (Mesh Master Node)
Main Wifi 5G: WORKING
Guest WiFi 2G&5G: WORKING
Firmware: 3.211
|
wired ethernet backhaul connection
|
GL-B1300 2 (Mesh Sub-Node)
Main WiFi 5G: WORKING
Guest WiFi 2G&5G: NOT WORKING (DHCP Problem)
Firmware: 3.211

The problem with the guest wifi on the mesh sub node is, that apparently the DHCP isn’t working properly. When I try to connect with a device, it won’t get an IP assigned and - after some time - selfassigns an IP (169.xxx.xxx.xxx) which of course isn’t working. DHCP on the main wifi on the mesh sub node is working without any problems.

After trying several things in the config last night, I resetted the mesh sub node back to factory settings and re-establsihed the basic mesh configuration by pairing the two routers as shown in the manual - which lead to a working main wifi and a non-working guest wifi on the mesh sub node again.

Yesterday, I checked the /etc/config/network file on the mesh sub node and did see, that the main wifi was set to option proto 'static' and the guest wifi was set to option proto 'dhcp' - which felt a little bit strange to me. However, since the main wifi was working, I tried to set the guest wifi to proto static aswell. After that, I was successfully able to connect clients to the guest wifi and get a correct IP from the guest wifi IP range. However, after that I had problems with the routing, traceroute on one of the clients told me, that the packets would only circulate on the mesh sub node for two times before being dismissed (routing loop). After several tries, I wasn’t able to fix that routing problem.
When I checked the /etc/config/network file today (after the reset), it showed option proto 'dhcp' for both networks - but again, the initial situation is same, main wifi working, guest wifi isn’t.

To be honest, right now I am a little bit confused and don’t really understand where the problem is. Maybe you can help me with that?

2

I further tracked it down and it seems to be a problem with the routing now. I did set the guest wifi to option proto 'static' which reliably provides correct IP addresses in the guest network range to my guest devices now. However, I still can’t connect to the internet. If I trace route google.de from the guest network, it gives the following figure:

traceroute to google.de (142.250.185.131), 64 hops max, 52 byte packets
 1  ((subnode hostname)) (192.168.9.1)  4.967 ms  2.015 ms  2.245 ms
 2  ((subnode hostname)) (192.168.9.1)  2.151 ms *  3.131 ms

So the packets don’t find their way to the gateway (10.0.2.1) and keep circulating on the B1300 mesh subnode with IP 192.168.9.1.
When I try to ping google.de from my guest device, it gives the following error:

PING google.de (142.250.184.227): 56 data bytes
92 bytes from ((subnode hostname)) (192.168.9.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 8bc8   0 0000  3f  01 dd95 192.168.9.197  142.250.184.227

Also this imho indicates there’s something wrong with the internal routing on the mesh subnode.

This is the output of the route command on the mesh subnode:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.2.1        0.0.0.0         UG    0      0        0 br-lan
10.0.2.0        *               255.255.255.0   U     0      0        0 br-lan
10.0.2.1        *               255.255.255.255 UH    0      0        0 br-lan
192.168.9.0     *               255.255.255.0   U     0      0        0 br-guest

For me this looks fine. Packets from subnet 192.168.9.0 (guest network) should use gateway 10.0.2.1 (just like the normal wifi network too). I have also checked the firewall config which also seems to be okay. At this point I am puzzled and have no idea, why the packets on the mesh subnode aren’t properly routed from 192.168.9.0 (br-guest) to gateway 10.0.2.1

Can you guys help?

3

This issue do exist when using mesh guest wifi with cable backhual. We’are trying to find a solution.
Does mesh with wifi okay with sub node guest wifi? You only need to remove the cable to check.

4

Edit: NO, I was wrong initially or it worked only for a very short period of time. Now again I have the same behavior (routing?-problem) like before, when connecting to the guest network and trying to traceroute an internet address, I see that the packets keep circulating internally on the mesh subnode.

— original message —

Yes, indeed. When switching from wired ethernet backhaul to WiFi backhaul, the guest network is working as intended on the mesh sub node.

I can use this solution as a temporary fix, however this is far from being ideal. The mesh subnode is right on the edge of the WiFi range of the mesh master - thus rendering the mesh highly unstable and reducing network throughput and increasing ping, both drastically.
Do you guys have any idea what might be the problem? I see that you already have tracked it down to some point and you might have some idea. Is there any possible solution for that in near future? How can I assist you with that issue? By running a few more tests / trying changes in the config / use beta firmware / etc.?

5

I put some effort to implement this, by trying to bridge eth0/eth1 vlan interface etc,
but failed, finally find that description in qualcomm wifi docs

“Guest network with traffic separation (using VLAN tagging for separation over backhaul) is
supported only with wireless backhaul. Support with Ethernet or PLC backhaul will be include in a
future release”

So I guess this feature is not that soon.