[RT-AX88U] Issue with WiFi while using Link Aggregation

[zacofunny]

Hi.
I'm experiencing issue while using LAN Link Aggregation. The problem is that WiFi stops work properly, i.e. both the networks 2.4G and 5G are visible for clients, however router doesn't accept clients during authorization.
Sometimes everything works with no issues until another restart router or switch (TP-Link TL-SG3424) that is connected to it. The problem disappears either when I disable Link Aggregation or when I unplug one of the wires from switch (without disabling Link Aggregation).

@RMerlin is this a known problem and is there any solution?

It looks strange for me that Link Aggregation and WiFi authorization is related in any way and it seems that there may be some bug in the firmware causing this issue.

I'm using 384.19
LAN - Switch Control settings:
Jumbo Frame = Disabled
Spanning-Tree Protocol = Enabled
Bonding/ Link aggregation = Enable

I disabled WiFi Smart Connect option so I manage 2.4G and 5G manually.
The link aggregation is made between TL-SG3424 switch and LAN ports 1 and 2 of the router.

 

[RMerlin]

I don't know.

 

[Elmer]

Running the same setup with no problems. Hardware issue? Maybe do a hard reset/reload?

 

[Maloon]

I have same issue using 2 RT-AX88U. Hard reset does not help.

But I think problem is not Wifi. I have packets dropped even with wired connections. Example: a host is wire connected and is asking for IP address, router receives it, and offers one, but packet never arrives to host, and host keeps trying and trying for a DHCP IP address. A reboot solves issue for a time (few days).

Tested scenarios, with 384.18 and 384.19:
- Router + AP connected directly with link aggregation.
- Router + AP connected with link aggregation to a root switch D-Link DGS-1210-24, with ports configured with link aggregation.
- Router + AiMesh Node connected by one wire from LAN to WAN, and router connected to root switch.

Ethernet wires are Cat.7, tested with certified tool.

Before, I had 2x RT-AC5300 using link aggregation without any issue.

 

[Elmer]

Can you show me the log entries that display the problem? I'll look for the same type of entries.

 

[Maloon]

Logs do not show specific things about bond link, but this is a sample log of a device trying to get IP address from DHCP, without success:

Sep 11 16:10:30 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:10:30 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
Sep 11 16:10:32 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:10:32 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
Sep 11 16:10:35 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:10:35 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
Sep 11 16:10:43 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:10:43 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
Sep 11 16:11:00 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:11:00 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
Sep 11 16:11:31 dnsmasq-dhcp[1938]: DHCPDISCOVER(br0) dc:4f:22:77:0d:04
Sep 11 16:11:31 dnsmasq-dhcp[1938]: DHCPOFFER(br0) 10.0.0.42 dc:4f:22:77:0d:04
...

 

[Elmer]

Nope, nada. No DHCPDISCOVER issues, and I have tons of connected devices - list shows 95.

 

[Maloon]

Did you set loglevel to "All"?

 

[zacofunny]

Running the same setup with no problems. Hardware issue? Maybe do a hard reset/reload?

I've tried it already. Hard reset doesn't help per se. Just, after some restarts including enablings/disablings of settings it starts work. I can't find the key rule here.
I believe that, the same symptoms can be observed when the router is connected with 2 wires to the switch without link aggregation enabled on it.
It looks like the conflict in transmission or something alike. But even in such case I can see no reason for non-working WiFi authorization due to such thing.
At the moment my router started to work properly. I've reset the settings in router and the switch, swapped cables few times ant it started work, until next time.

 

[Elmer]

I do have all logs displayed. Using scribe/uiscribe and believe me, when I first started messing around with DNS-over-TLS, I had some dnsmasq errors (like wall to wall). Good luck. I'm running on gig fiber with Skynet and no qos/trendnet (using acceleration/cache) and I'm currently in hog heaven. Most heavy traffic goes to the switch (try to keep most streaming connections wired), and the switch has qos enabled. I have some cameras that are heavy wireless users but I connect them to a wireless node that's managed by the switch.

 

[Squall Leonhart]

I can confirm this, AX88U as source with AC88U as downstream in, don't even have the radio's turned on on the AC88U


How very odd.

 

[Ripshod]

I can confirm this, AX88U as source with AC88U as downstream in, don't even have the radio's turned on on the AC88U


How very odd.

You may find it better to post a new thread, rather than necro-posting to a thread that's been dead nearly 4 years.
Point to note - I'm running LAG(LACP) to a switch and no wifi problems.

 

[Squall Leonhart]

Theres no point to making a duplicate thread for an issue that is the same, doesn't alter the reading of the thread and adding more search results to google that are a dead end helps nobody.

I suspect the issue is due to the faux packet loss that layer 3+4 mode can cause when packets are out of order, since this is the default mode for the RX88U, rather than the spec compatible layer 2 or 2+3 modes.