No seamless WiFi handoff from VR1600v to DSL-2544N (MAC flush issue?)

[pvautrin]

Hi,

I'm trying to set up seamless WiFi handoff (same SSID&WPA2-PSK/AES) between Archer VR1600v (provided with TPG NBN HFC) and D-Link DSL-2544N (provided with TPG Naked DSL), but it only works in one direction.

NBN HFC box is connected to VR1600v (HW: v2 / FW: 0.1.0 0.9.1 v5006.0 Build 190228 Rel.72265n), itself hard wired (CAT5E) to DSL-2544N (FW: AU_1.18).

When moving from DSL-2544N range to VR1600v range, WiFi handoff with Android devices is seamless.

When moving from VR1600v range to DSL-2544N range, WiFi data stops and Android devices switch to 4G. When checking WiFi connections on Android device, DSL-2544N access point reports "Failed to obtain IP address" for roughly 3 minutes, after which it connects again to DSL-2544N access point. If I try again but this time move back within VR1600v range before the 3 minutes, connection back to VR1600v access point is instantaneous.

My conclusion is that VR1600v does not flush my devices' MAC addresses (learned against the WiFi port) upon handoff to another access point, and therefore does not forward traffic to the LAN port towards the DSL-2544N until MAC aging timer expires.

Can a Tier2/3 technician investigate and advise of any suitable VR1600v firmware to use?

Both devices are standard from TPG so this should be easy to replicate.

Thanks,

PY

[david64]

Hi pvautrin. Is there anything in the system logs of the routers to indicate what they are doing regarding the wifi device? Especially the Failed message.

What are the DHCP setting and dynamic pool range on each router?

Are there other wifi devices in use at the time you do this test? Or any cabled devices?

[pvautrin]

Hi David,

I ran further tests by swapping DSL-2544N (now connected to NBN HFC box, with WAN settings and DHCP) and VR1600v (now 2nd WiFi AP, WAN settings and DHCP disabled), and even adding a 3rd WiFi AP connected behind the VR1600v (all using same SSID&WPA2-PSK/AES). The below results point to VR1600v being the culprit. Logs are all but empty (even with Debug enabled), and clients were limited to one wired and one wireless (Android).

Are you able to replicate this behaviour? Both devices are from TPG.

16:26 - Power on DSL-2544N

16:28 - Wired client receives 192.168.1.3 (out of a DHCP range of 192.168.1.2 to 192.168.1.99)

16:36 - Power on VR1600v

16:38 - Connect VR1600v to 3rd WiFi AP (DD-WRT)

16:40 - Wireless client "WL1" enabled near DSL-2544N, receives 192.168.1.4

16:42 - Relocate WL1 near VR1600v -> WiFi AP connection times out after ~30s

16:43 - Relocate WL1 near 3rd WiFi AP -> WiFi AP reconnects instantly

16:44 - Relocate WL1 near VR1600v -> WiFi AP connection times out after ~30s

16:45 - Relocate WL1 near DSL-2544N -> WiFi AP reconnects instantly

16:46 - Relocate WL1 near VR1600v -> WiFi AP connection times out after ~30s

16:47 - WL1 still near VR1600v -> Failed to obtain IP

16:53 - WL1 still near VR1600v -> WiFi AP reconnects by itself

16:54 - Relocate WL1 near DSL-2544N -> WiFi AP stays connected

So this confirms handover works from VR1600v to DSL-2544N, but not the other way.

DSL-2544N logs:

Manufacturer: D-Link
ProductClass: D-Link DSL-2544N
SerialNumber: 7062b886ea7f
IP: 192.168.1.1
HWVer: T1
SWVer: AU_1.18

[power cycle]
1970-01-01 11:01:04 [6] syslog: Accessor:[CPE] Method:[NotiInform] Para:[type=2] Result:[0]
1970-01-01 11:01:04 [5] syslog: Accessor:[CPE] Method:[PPPoE] Para:[User=pierreyv ip=61.68.75.142] Result:[0] Wan Link was Connected
2020-12-26 16:28:50 [5] syslog: Accessor:[CPE] Method:[AUTH] Para:[] Result:[9007] Not found session 162d7075, user login check failed
2020-12-26 16:29:01 [5] syslog: Accessor:[CPE] Method:[AUTH] Para:[] Result:[] User admin login success

VR1600v logs (Debug level):

2016-01-01 11:00:36 [7] VoIP: rule 0x10300300 added for '000' (ebl 3 br 0 s 0 l 3 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 000)
2016-01-01 11:00:36 [7] VoIP: rule 0x10300300 added for '106' (ebl 3 br 0 s 0 l 3 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 000)
2016-01-01 11:00:36 [7] VoIP: rule 0x10a00300 added for '0xxxxxxxxx' (ebl 3 br 0 s 0 l 10 T 0 # 0 P 0 S 1 E 0) map(dot 000 d
2016-01-01 11:00:36 [7] VoIP: rule 0x10800300 added for 'xxxxxxxx' (ebl 3 br 0 s 0 l 8 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 3ff
2016-01-01 11:00:36 [7] VoIP: rule 0x10300300 added for '111' (ebl 3 br 0 s 0 l 3 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 000)
2016-01-01 11:00:36 [7] VoIP: rule 0x10800300 added for '1345xxxx' (ebl 3 br 0 s 0 l 8 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 3ff
2016-01-01 11:00:36 [7] VoIP: rule 0x10600300 added for '134xxx' (ebl 3 br 0 s 0 l 6 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 3ff)
2016-01-01 11:00:36 [7] VoIP: rule 0x10800300 added for '13xxxxxx' (ebl 3 br 0 s 0 l 8 T 0 # 0 P 0 S 1 E 0) map(dot 000 d 3ff
2016-01-01 11:00:36 [7] VoIP: rule 0x10c00300 added for '183xxxxxxxxx' (ebl 3 br 0 s 0 l 12 T 0 # 0 P 0 S 1 E 0) map(dot 000
2016-01-01 11:02:23 [5] System: LAN2 link up 100 mbps
2016-01-01 11:13:18 [5] System: DSL training G.992 started