ER605 Upgrade won't run with my existing & working config
The latest firmware will not work with my existing config which runs fine on version 1.1.1 Build 20210723 Rel.64608. I have spent many hours doing many things to try and get a good result bu to no avail. The problem is best illustrated by the following scenario (hardware version is V1.0):
1.With 1.1.1 Build 20210723 Rel.64608 loaded prior to upgrade:
1.1 Save config file
1.2 Factory reset router
1.3 Load saved config file
1.34 Check all good (it is)
2 After upgrade to ER605(UN)_V1_1.2.0 Build 20220114
2.1 Doesn't route and can't communicate with router. Not even a ping at either the config files static address or the routers default 192.168.0.1
2.2 Factory reset
2.3 New firmware runs fine on default config
2.4 Load config file saved in 1.1 above
2.5 Doesn't route and can't communicate with router. Not even a ping at either the config files static address or the routers default 192.168.0.1
etc etc
3. Context:
3.1 Router is totally stand alone with just a laptop connected to ER605 port 5 and works fine with the old firmware
3.2 All variations of IP addressing tried: nailing up both ends, DHCP at each end in turn pinging all plausible addresses etc etc
3.3 Main config features are: 2xWAN ports, 6 VLANS (including "1") all tagged on port 4, Ports 3&5 untagged VLAN 1, Individual DHCP for each VLAN
4. Clue (maybe)
4.1 When playing with the Router and laptop IP addresses regardless of settings (I think) the router redirects the webpage to an autoconfiguration address (160.x.x.x) before falling silent.
4.2 Whilst the router does not respond to pinging, it times out at the expected address rather than be declared "unreachable" like all the other addresses. This suggests ARP worked at least briefly.
A fix would be much appreciated. I have just purchased three of these for a system upgrade and want to start them off with the latest firmware. I certainly don't want to put them in to service if they are not upgardeable.
Thanks
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi, very sorry for this inconvenience. The senior engineer has confirmed that this is a "glitch" due to the new ACL mechanism introduced in 1.2.0 firmware. And it's been reported to the R&D. For the next firmware update, I cannot give a specific date but it will be soon. Please rest assured.
At this moment, you can still create multiple ACL rules to achieve your purpose.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
What is the exact hardware version of your device? On the printed label.
I want to know can you successfully load the backup to 1.2.0 or not.
From what you described, that is you can load but after you load the backup, nothing previously configured works on 1.2.0..
Well, when you cannot ping the IP, what is the IP on your PC when you do the ping? Same subnet with the router that has loaded the backup?
- Copy Link
- Report Inappropriate Content
Thanks for your post.
As per my original post:
- Hardware version is V1.0
- All reasonable permutations were tried with pinging (I have 40 years of networking experience) eg:
-- nailing up both laptop and router (via config file),
-- Router as DHCP server, laptop as client
-- DHCP server connected to both laptop and router
-- Always on subnet 192.168.0.0/24,
-- using both my configured address for the router (192.168.0.123) and its default (192.168.0.1).
-- Laptop nailed up at 192.168.0.100 except when trying DHCP.
There is one typo in my original post I wrongly quoted 160.x.x.x as the autoconfig IP address seen on browser redirection. That should have read 169.x.x.x
- Copy Link
- Report Inappropriate Content
Ok, Finger pointing done and bug pinned down. Version 1.2 is wrongly applying a firewall access control rule that works as you would expect and as anyone would want in SW ver 1.1.1.
RULE
Name: IPGROUP_LAN_Isolation (default "IPGROUP_LAN" is subnet 192.168.0.0/24 on VLAN 1)
Source Network: !IPGROUP_LAN (note the "!" at the front meaning "everything that is not IPGROUP_LAN")
Destination Network: IPGROUP_LAN
Policy: Block
Service Type: All
Direction LAN->LAN
Effective Time: Any
With version 1.1.1 software this does what I expect and want which is to block access to IPGROUP_LAN from all other LANs thereby isolating it. I have tailored versions of the rule for each of my 5 networks. This isolates each network from all the others and is a cornerstone of my security policy.. It work well on V1.1.1 frimware.
With version 1.2 the firmware gets carried away and blocks traffic between valid members of "IPGROUP_LAN" as well. This leaves you unable to communicate on any LAN port included in such a rule. Effectively you can't even talk to yourself!
To reproduce the problem (do as a bench setup not connected to a real network)
1. Set factory default config
2. Load 1.2 Firmware
3. Enable remote management via the WAN port (normally taboo for me) with subnet 0.0.0.0/0 permissions (keeping it simple)
4. Nail up the WAN IP to something other than the default LAN 192.168.0.0/24 subnet (eg 192.168.1.1)
5. Connect a client (laptop etc) to the WAN port nailed up on the same subnet as the WAN (eg 192.168.1.50) (a router reboot may be needed here)
6. You should now be able to use the http interface to gain access to the settings without using the LAN connections (eg via http://192.168.1.1)
7. Using a different client (laptop etc) on a LAN port You should also be able to ping the router at its default LAN address 192.168.0.1 at this stage
8. You can also access the config screens from the LAN port at this stage.
9. Now go into "Firewall"/"Access Control" and add a rule using the parameters specified in "Rule" above. (it does not matter that you only have one network configured)
10. As soon as you have entered the rule you will be locked out of the LAN interface and unable to even ping it. It will though show up on an ARP scan from another device on the subnet but that is of little use.
11. If you now delete the rule using the WAN interface you will again have access on the LAN side.
I can't role out these new routers without knowing a fix is on the way otherwise I would get locked in to V1.1.1 and that might be bad in the future. Does anybody reading this know the best route to get the TP-Link team to pursue a fix? I have a shed full of TP-Link kit but never before a problem like this one. If it can't/isn't going to be fixed then I need toi send the routers back while I still can.
Any help much appreciated.
- Copy Link
- Report Inappropriate Content
Hi, very sorry for this inconvenience. The senior engineer has confirmed that this is a "glitch" due to the new ACL mechanism introduced in 1.2.0 firmware. And it's been reported to the R&D. For the next firmware update, I cannot give a specific date but it will be soon. Please rest assured.
At this moment, you can still create multiple ACL rules to achieve your purpose.
- Copy Link
- Report Inappropriate Content
The next update (v1.2.1) has just been released and this bug is still not fixed.
I'm wondering... how did the developers tested this before releasing the new firmware?
- Copy Link
- Report Inappropriate Content
Arion wrote
The next update (v1.2.1) has just been released and this bug is still not fixed.
I'm wondering... how did the developers tested this before releasing the new firmware?
Hi @Arion
Under my test we can use ! on ACL now, means the new firwmare have fixed this issue. Can you share your ACL configurations and your network requirement, so I can do further test?
- Copy Link
- Report Inappropriate Content
My config had been posted on the forum here previously.
I wish it was any error by me... but with v1.1.1 it works.
I have selected an unused vlan as source network like this: !vlan99
And the same as destination network: !vlan99
...to ensure that every single vlan is isolated from each other.
I can see that others have posted on the forum a slightly different setup, choosing IPGROUP_LAN (or _ALL?) as destination network.
I've never understood why they do that and what's the most proper way to isolate vlans. Also, in my experience, when I tried to block each vlan from others, it wasn't enough doing so one direction. The rule didn't work bi-directionally.
I'd like to find an instruction from a TP-Link expert about how to isolate every vlan from each other, in standalone mode.
The thing is, I also tried, based on my configuration, changing that ACL rule from Block to Allow before doing the firmware update and in that case it succeded to reboot, then I changed it back to Block in the new firmware and after a few moments it managed to refresh the config page but only once, then became unaccessable again. Therefore I'm stating that the v1.2.1 still can't work with "!" ACL rules.
Edit:
Just a thought. Do I have to create another ACL rule with higher priority that allows all type from !vlan99 to IPGROUP_LAN?
Does IPGROUP_LAN is the management vlan (being 192.168.0.0/24) that operates the router?
Would it solve the operation between the vlans and the router and the traffic to the internet and still not interconnecting any vlans with each other?
- Copy Link
- Report Inappropriate Content
Have you or your team tested a config similar to mine since then?
I'm not in a hurry at the moment as I can't interrupt the router's operation until the end of Fall but I'm curious how is it that for me it doesn't work and for you it did.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1424
Replies: 9
Voters 0
No one has voted for it yet.