10-20-2019 01:38 PM
After upgrading my SG200-26 switch to 1.4.11.02, I can no longer access it from Chrome (version 77.0.3865.120).
I have cleared the cache, history, etc from my browser. I have rebooted both the switch and the computer I am trying to access it from.
The only browser extension I have installed is uBlock Origin. I have added the FQDN that's assigned to the SG200-26 to this extension's whitelist.
Is this a known issue? Any suggestions on how to recover without doing a factory reset?
Solved! Go to Solution.
10-28-2019 07:28 AM
Hello,
I'm seeing similar issues on the SG300 switches after the 1.4.11.02 release upgrade.
In my case I have a wildcard certificate on the switches and am using HTTPS only. I can't access the web interface via the DNS name but can via the IPv4 address (obviously with certificate errors). It's not a name resolution issue- definitely something up on the swtiches.
I've tried reverting to the default cert but that doesn't help either. So doesn't seem to be certificate related.
IPv6 access to the web interface is also broken- but this seems to be a known issue and is listed in the release notes. That may explain why others are not able to reach their web interfaces perhaps.
I agree a factory reset to resolve this isn't a great resolution. It's a big job to rebuild a network of these switches that way....
Kind Regards,
Andy.
10-20-2019 02:14 PM
Try clear the browse cache or different browser, if all tried best option is contact SMB TAc support, they can asists better and quicker.
10-21-2019 03:16 AM
10-21-2019 04:42 AM - edited 10-27-2019 10:22 AM
May be but bare in mind factory reset clear all your config. if this acceptable, try that is no harm
Personally i suggest to call SMB Tac about the issue, so they may have a quick fix for you, end you can reset the device any time.
10-27-2019 09:28 AM
The Edge browser does not work either.
I don't now what the TAC is, but it sounds like it probably requires a support contract which I do not have.
My configuration is complex. I am trying to avoid a reset if possible. Also, if a reset does not solve the problem and I can't get back in to reconfigure, my whole network is hosed and I'm down for the count. so, this is not an option until Cisco reproduces the problem with the exact same hardware / firmware and verifies that a factory reset will fix the issue.
Using wget, I get the following:
[root@my-host ~]# wget -d --no-check-certificate https://my-switch.example.com Setting --check-certificate (checkcertificate) to 0 DEBUG output created by Wget 1.14 on linux-gnu. URI encoding = ‘UTF-8’ Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) --2019-10-27 09:21:16-- https://my-switch.example.com/ Resolving my-switch.example.com (my-switch.example.com)... 192.168.1.101 Caching my-switch.example.com => 192.168.1.101 Connecting to my-switch.example.com (my-switch.example.com)|192.168.1.101|:443... connected. Created socket 3. Releasing 0x000000000181f8f0 (new refcount 1). Initiating SSL handshake. Handshake successful; connected socket 3 to SSL handle 0x0000000001828360 certificate: subject: /CN=my-switch.example.com issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 WARNING: cannot verify my-switch.example.com's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3’: Unable to locally verify the issuer's authority. ---request begin--- GET / HTTP/1.1 User-Agent: Wget/1.14 (linux-gnu) Accept: */* Host: my-switch.example.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 400 Bad Request ---response end--- 400 Bad Request Registered socket 3 for persistent reuse. ] done. 2019-10-27 09:21:17 ERROR 400: Bad Request.
This is a very breaking change. It should have never gotten past QA. Other users are experiencing it on other models as well. Even if a firmware fix were offered, we can't get into the switch to update the firmware.
Is there a command-line interface to the SG200-26? I've never found one.
What are we to do? How do we recover from this, Cisco?
10-28-2019 01:18 AM
Hi,
Factory reset solve this problem, but you cannot use previously saved backup for restore old config. When you restore the old config, switch again became unresponsable with web. I configured it again manually after factory reset.
For complex config this is very bad.
10-28-2019 07:28 AM
Hello,
I'm seeing similar issues on the SG300 switches after the 1.4.11.02 release upgrade.
In my case I have a wildcard certificate on the switches and am using HTTPS only. I can't access the web interface via the DNS name but can via the IPv4 address (obviously with certificate errors). It's not a name resolution issue- definitely something up on the swtiches.
I've tried reverting to the default cert but that doesn't help either. So doesn't seem to be certificate related.
IPv6 access to the web interface is also broken- but this seems to be a known issue and is listed in the release notes. That may explain why others are not able to reach their web interfaces perhaps.
I agree a factory reset to resolve this isn't a great resolution. It's a big job to rebuild a network of these switches that way....
Kind Regards,
Andy.
10-28-2019 04:03 PM
Oh wow, accessing via IP address rather than host name worked for me too. Thank you, that really saved the day!
It would sure be nice if someone from Cisco acknowledged this bug, confirmed it is in their bug tracking system, and will be fixed in the next release. I don't know off-hand if this is purely a community forum, or if Cisco employees also keep any eye on what's going on so as to get bugs into the bug tracking system.
10-29-2019 01:07 PM
What a shame. It's just poor that this update passes QA. Go to hell!
10-29-2019 01:09 PM
Please remove the word "professional" from all your websites. Haha Cisco
... will switch to other products in future.
12-07-2019 09:16 PM
As the SG300 switches are now beyond the last software support date, I suspect there will never be an official fix (the 1.4.11.2 release was likely queued before the end of software support date, and got pushed out along with the other related fixes for the same bug at the same time which was technically after the end of software support). Looks like it is time to schedule the hardware refresh.