Omada TL-R605 PVID - Network connection is lost when I change PVID from the default value
Omada TL-R605 PVID - Network connection is lost when I change PVID from the default value
- TL-R605 v1.0 1.3.0
- Omada Software Controller 5.9.31
- TL-R605 v1.0 1.3.0
- Omada Software Controller 5.8.4
- TL-R605 v1.0 1.2.1
- Omada Software Controller 5.8.4
I don't know if there is an issue with the firmware or I'm doing something wrong.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
I had to ditch the Omada Controler and restored the R605 router with the previous configuration. Now all the networks behave as expected.
I hope that this bug is corrected in the future.
- Copy Link
- Report Inappropriate Content
There is a FAQ on this as it's not obvious (pay attention to Step 4):
https://www.tp-link.com/us/support/faq/2814/
- Copy Link
- Report Inappropriate Content
@d0ugmac1
Thank you for your quick response, however I'm neither using a omada capable switch nor I'm trying to change the management vlan.
I'm creating a new /24 network on a port on a R605 router. My problem is that Since you can't unselect VLAN 1, so the port in question has VLAN1 and VLAN40 (my case). If I leave the default port configuration DHCP will configure the hosts in VLAN1 (can access the internet but it's not the configuration I want). If I switch the PVID to 40, DHCP will correctly configure the hosts to VLAN 40 (192.168.40.0/24) but I can no longer access the internet or the default gateway.
- Copy Link
- Report Inappropriate Content
Thanks I understand your issue more clearly now. Unfortunately, my local ER605v1 is still undergoing memory leak testing at this time and I can't really mess up the test which has been going 6+ weeks now. My remote units are on 1.3.0 but I have no way to test.
You should always use the latest controller version. Device firmware will tell you the minimum controller version needed to utilize all features, but it's ok to use the most recent controller. Please revert to 1.3.0 and 5.9.x
I know the PVID feature on the routers was very recently introduced so there's a chance of a bug which would warrant a ticket. However, the routers sometimes need a full power cycle when significant changes are made to their routing configuration before it takes properly. Please re-upgrade the firmwares, factory default the ER605 and then re-adopt it. Re-test. If devices connected to a non-default VLAN port on the ER605 still cannot reach the internet, please examine your Routing Table and possibly add a static default route for the subnet.
I would be curious to see the output of a device when it:
a) ping 192.168.20.1
b) ping 192.168.0.1
c) ping 8.8.8.8
d) traceroute 8.8.8.8
I'll wait to hear back from you.
- Copy Link
- Report Inappropriate Content
I upgraded to the following versions.
- TL-R605 v1.0 1.3.0
- Omada Software Controller 5.9.31
I factory defaulted the router via forget and re-adopted it. Tested and the issue remained. I re-booted and no change.
These are the outputs that you requested
ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 56(84) bytes of data.
From 192.168.40.100 icmp_seq=1 Destination Host Unreachable
From 192.168.40.100 icmp_seq=2 Destination Host Unreachable
From 192.168.40.100 icmp_seq=3 Destination Host Unreachable
ping 192.168.40.1
PING 192.168.40.1 (192.168.40.1) 56(84) bytes of data.
From 192.168.40.100 icmp_seq=1 Destination Host Unreachable
From 192.168.40.100 icmp_seq=2 Destination Host Unreachable
From 192.168.40.100 icmp_seq=3 Destination Host Unreachable
ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.40.100 icmp_seq=1 Destination Host Unreachable
From 192.168.40.100 icmp_seq=2 Destination Host Unreachable
From 192.168.40.100 icmp_seq=3 Destination Host Unreachable
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.40.100 icmp_seq=1 Destination Host Unreachable
From 192.168.40.100 icmp_seq=6 Destination Host Unreachable
From 192.168.40.100 icmp_seq=7 Destination Host Unreachable
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 debian (192.168.40.100) 2631.437 ms !H 2631.387 ms !H 2631.368 ms !H
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.40.100 netmask 255.255.255.0 broadcast 192.168.40.255
inet6 prefixlen 64 scopeid 0x20<link>
ether txqueuelen 1000 (Ethernet)
RX packets 18365190 bytes 17663973321 (16.4 GiB)
RX errors 0 dropped 554563 overruns 0 frame 0
TX packets 7590666 bytes 1643004483 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Currently scanning: Finished! | Screen View: Unique Hosts
241 Captured ARP Req/Rep packets, from 6 hosts. Total size: 14460
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.0.5 234 14040 Unknown vendor
192.168.40.2 1 60 Unknown vendor
192.168.40.6 3 180 Unknown vendor
192.168.40.7 1 60 Unknown vendor
192.168.40.12 1 60 Unknown vendor
192.168.30.105 1 60 TP-LINK TECHNOLOGIES CO.,LTD.
I couldn't create a route table entry since I don't have a next hop to point to.
If you need additional information, please let me know.
- Copy Link
- Report Inappropriate Content
Ok, the most interesting thing for me is this:
It seems improbably that a device that is getting its IP info from a DHCP server cannot ping it.
Can you confirm that this interface is getting it's configuration via DHCP and was not statically configured by you?
What is the output of 'netstat -nr' ?
To me it looks like the router may still be 'tagging' routed packets for VLAN40 (which would be fine if there was a switch downstream that actually untags it before it hits your end user device). If the ER605 is adding VLAN40 tags then that would make them invisible to your client device and it would only see local devices.
I think the next step assuming I haven't hit something already, would be to do a packet capture (Wireshark or equiv) to look at exactly how those packets are arriving on the interface from the router. You are clearly getting packets as the Mbyte count is pretty high for an 'isolated' device.
- Copy Link
- Report Inappropriate Content
It seems improbably that a device that is getting its IP info from a DHCP server cannot ping it.
Yes, I think so too.
Can you confirm that this interface is getting it's configuration via DHCP and was not statically configured by you?
Yes
What is the output of 'netstat -nr' ?
netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.40.1 0.0.0.0 UG 0 0 0 enp5s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 enp5s0
192.168.110.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr2
192.168.120.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr3
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Packet Capture
I captured the moment the host received the ip from the DHCP
113 28.176003513 EliteGro_→ Broadcast ARP 60 Who has 192.168.40.6? Tell 192.168.40.2
114 28.450720504 Tp-LinkT_ → Broadcast ARP 60 Who has 192.168.0.2? Tell 192.168.0.1
115 28.962945937 → Broadcast ARP 60 Who has 192.168.40.1? Tell 192.168.40.101
116 29.019509449 Tp-LinkT_ → Broadcast Realtek 60
117 29.199908945 EliteGro_ → Broadcast ARP 60 Who has 192.168.40.6? Tell 192.168.40.2
118 29.986829576 → Broadcast ARP 60 Who has 192.168.40.1? Tell 192.168.40.101
119 30.020112923 Tp-LinkT_ → Broadcast Realtek 60
120 30.223802271 EliteGro_ → Broadcast ARP 60 Who has 192.168.40.6? Tell 192.168.40.2
121 30.888731265 0.0.0.0 → 255.255.255.255 DHCP 332 DHCP Request - Transaction ID 0xce12c12b
122 30.891301339 192.168.40.1 → 192.168.40.102 DHCP 355 DHCP ACK - Transaction ID 0xce12c12b
123 30.899818906 :: → ff02::16 ICMPv6 110 Multicast Listener Report Message v2
124 30.924978898 Elitegro_ → Broadcast ARP 42 ARP Announcement for 192.168.40.102
125 30.927780417 192.168.40.102 → 224.0.0.22 IGMPv3 54 Membership Report / Join group 224.0.0.251 for any sources
126 30.958652626 Elitegro_ → Broadcast ARP 42 Who has 192.168.40.1? Tell 192.168.40.102
127 30.958871127 Tp-LinkT_ → Elitegro_ ARP 60 192.168.40.1 is at c0:c9:e3:
128 30.971807469 :: → ff02::16 ICMPv6 110 Multicast Listener Report Message v2
129 31.010501726 → Broadcast ARP 60 Who has 192.168.40.1? Tell 192.168.40.101
130 31.018167807 192.168.40.102 → 224.0.0.251 MDNS 87 Standard query 0x0000 PTR _ipps._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question
131 31.021354203 Tp-LinkT_ → Broadcast Realtek 60
.
139 31.983772401 Elitegro_ → Broadcast ARP 42 Who has 192.168.40.1? Tell 192.168.40.102
140 31.984045877 Tp-LinkT_ → Elitegro_ ARP 60 192.168.40.1 is at c0:c9:e3:
141 32.019246165 192.168.40.102 → 224.0.0.251 MDNS 87 Standard query 0x0000 PTR _ipps._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question
142 32.024843816 Tp-LinkT_ → Broadcast Realtek 60
143 32.034932907 → Broadcast ARP 60 Who has 192.168.40.1? Tell 192.168.40.101
.
147 32.925087691 Elitegro_ → Broadcast ARP 42 ARP Announcement for 192.168.40.102
To me it looks like the router may still be 'tagging' routed packets for VLAN40 (which would be fine if there was a switch downstream that actually untags it before it hits your end user device). In my case I’m using a non-managed switch for this network so no untagging occurs. You are clearly getting packets as the Mbyte count is pretty high for an 'isolated' device. I need that this machine access the internet so what I do is change the PVID back to the default and I get access again (but in the LAN network not subnet I created). Maybe I’m over complicating things. Let me tell you what I’m trying to accomplish, maybe there is a simpler solution. I want to create a /24 subnet on a port of the router. Doesn’t need VLANs. To that port I’ve attached an unmanaged switch where I’m attaching all hosts. The router provides the DHCP service for all hosts in the network. I’ll be creating ACLs to control the access to the network.
- Copy Link
- Report Inappropriate Content
I think there is a firmware problem. @Hank21 should consider this for a support ticket.
As I see it, the router is not correctly responding to ARPs, given what look to be malformed responses. It's possible that this particular use case of just a Controller and ER605 was not tested.
Here's what an ARP looks like for me
- Copy Link
- Report Inappropriate Content
I'm sorry, I may have confused you, I erased part of all mac addresses for privacy issues. The mac address is not malformed. I should have stated it in the post.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1813
Replies: 18
Voters 0
No one has voted for it yet.