Bad update on 8 port Gs108eV3

[tmittelstaedt]

Thought I would ask and possibly warn people about this.

I have a GS108Ev3 on the bench.  It was in use for about 2 years.   I attempted to update it with the latest firmware off the Netgear website using Chrome.   The switch went into firmware upload mode fine, it took the upload file.   Then I got a browser error that the switch was no longer communicating.

I can pin reset it, and it reverts to the 192.168.0.209  ip number.  But any attempt to access it with a web browser and no joy.  I also tried accessing it with the ProSafe utility and that utility sees it but says it must be configured with a web browser.

So I guess the latest firmware is designed to take a managed switch and turn it into an unmanaged switch.  /s

Any suggestions on recovery?

[DaneA]

@tmittelstaedt,

Welcome to the community! 🙂 

Kindly try to disconnect the GS108Ev3 from your existing network. Then, connect a PC/laptop directly a LAN port of it.  Try to access its web-GUI using its default IP Address which is 192.168.0.239.  You can also check if you can get replies when you ping the default IP Address of your  GS108Ev3. 

Regards,

DaneA

NETGEAR Community Team

[tmittelstaedt]

>Kindly try to disconnect the GS108Ev3 from your existing network

That is what "I have the switch on the bench" means.

Bench testing means completely disconnected from the network and on a workbench.  Please add this term to your

vocabulary.  Here is an explanation:  https://en.wikipedia.org/wiki/Test_bench

>connect a PC/laptop directly a LAN port of it

That is implied by "bench testing"

>Try to access its web-GUI using its default IP Address which is 192.168.0.239.

I already said in my post that I had tried this on the bench

>You can also check if you can get replies when you ping the default IP Address of your GS108Ev3.

I do get replies from it when it's on the bench.   As I stated already in my original post Prosafe connects to it which would

not be possible if the IP stack was not working at all.  But the web GUI does not come up when attempting to access

with a web browser.

[schumaku]

Recent Smart Managed Plus update switch IP stack seems to be cumbersome on the MTU  - double check if there is an MTU lower than 1500 is in place on the Web browser host.

Please provide more details (e.g. the original and the current updated firmware version) if you like to bring up any kind of "warning".

[tmittelstaedt]

You have to be kidding.  I already said the laptop with the web browser on it is plugged into the ethernet switch by an ethernet cable.  It is the laptop, the cable, and the switch.  That is all that there is on the bench   Why do you guys insist on believing the switch is in some esoteric weird configuration where I'd even be able to muck around with MTU?  MTU on ethernet is 1500.

And as for the prior firmware version, there is nothing in the readme that says users should NOT be able to go directly to the latest firmware for the switch from any prior version of firmware.  So unless that is the case i have done everything in the instructions for firmware version 2.06.14 and now have a switch that is no longer manageable.  So a warning is justified.  Update to the latest version if you dare.

[tmittelstaedt]

Incidentally, the prior firmware was 2.06.10   I had ZERO problems upgrading to this from 2.06.08  Just used the original Internet Explorer and follow the instructions from the webinterface of the switch.  It took the switch a while to apply the firmware but it worked.  And the 2.06.10 firmware worked.

The 2.06.14 firmware load absolutely will kill this switch.  DO NOT USE!   This is the grey version 3 non-POE switch.

[schumaku]

---

@tmittelstaedt wrote:

Why do you guys insist on believing the switch is in some esoteric weird configuration where I'd even be able to muck around with MTU?

---

Nobody insists here. It's just an information that some recent updates of certain hardware design model Plus switch IP stack caused a problem in case there is a lower MTU in the data path.

@tmittelstaedt wrote:

MTU on ethernet is 1500.

---

This might be the common default, and is the standard value according to the IEEE, indeed. To many "geeks" in the net explaining non-experienced users on how to "optimize" the MTU, having to adjust the MTU to cover some strange xDSL protocol encapsulations, and much more. In my opinion, an Ethernet adapter (Mac or Win) MTU can be set to 9000 especially if heavily using storage access, e.g. by higher SMB protocol versions. For all other use case, the PMTUD will do it's job, permitting no monkey decided to block all or specific PMTUD required ICMP in the data path.

We had several community members which discovered lowered MTUs on Ethernet (on the direct cable path) as well as on WiFi adapter the last few weeks, so nothing is impossible.

C:\>netsh interface ipv4 show interfaces

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
...
12 35 1450 connected WiFi 2
27 25 9000 connected Ethernet 2
...

Yes, I was just working on Beta testing a coming-up Netgear Plus switch model, so run a test drive on a lowered MTU on the WiFi adapter connection. And the good news is this model tested isn't affected.

Please understand this is a community, Members - especially those unpaid ones without a Netgear batch - don't need lectures on esoterics, weirdness, or what posters understand as bench testing. Let's keep this community as a friendly place. And sometimes I'm really kidding.

[tmittelstaedt]

As it turned out, yes this was the problem.  Unknown to me the MTU on the Ethernet interface on my laptop was set to 1300.  I don't know WHY it was set to that but my STRONG suspicions are that the Cisco IPSec VPN client that I have loaded on it reduced the MTU.

So, I will NOT modify my warning due to the following:

1) Netgear changed this due to some completely unnecessary monkeying around inside the switch firmware to try and implement a "security" thing of sorts.  At least that is what was told to me by Netgear support when I called in to try to get more information.  The engineers know they screwed up and there IS a "fix" in the works for this - in the next firmware version for this switch.  Interestingly, this switch is due to go off Netgear's firmware support as of 6/30/2021 according to a document on the Netgear site so someone clearly got their hind end chewed by this for them to violate their EOL policy.

2) Even though this is a showstopper bug Netgear has not pulled the firmware.  Nor have they modified the readme to warn people.  This is a showstopper because small low-port-count managed switches are de-rigueur in small remote 2-3 person sattelite offices that are behind site-to-site fixed VPNs.  And sometimes those VPN's are things like OpenSSH/OpenSSL VPN's which have reduced MTU, or are riding on PPPoE Internet connections with reduced MTU.  So an admin at a central headquarters who is under an IT Department policy to keep all network components at current firmware levels is going to get a VERY unpleasant surprise if they remotely update the switch.

I will point out the most recent version of OpenVPN introduced a bug where it improperly calculates it's internal MTU sizes on Linux K3.0 and later kernels for the internal tun interface it uses.  For certain packet sizes it simply drops the packet completely without sending back any ICMP "packet too large" messages.  Thus there is no guarantee PMTUD will work in all cases.  Assuming MTU is always 1500 is a very very BAD mistake for a switch firmware programmer to make.

3) According to Netgear support this bug affects ALL PROSAFE SWITCHES that run the 2.06.14 firmware REGARDLESS of port count.

4) MTU path discovery only works if the remote is able to respond back at lower MTU sizes.  This firmware prevents that so anyone running wireshark to try to figure out what is going on isn't going to see any packet exchange that has any meaning.

5) The de-facto standard for MTU on the Internet today is 1500, period.  There is NOT an "optimal" MTU that is smaller than that, all smaller MTUs are sub-optimal.  PPPoE links use 1492 but they are the only link in common use on the Internet by ISP's and large public networks and most ISP's are phasing them out because of problems like this.  Jumbo Ethernet frames, OC3, Sonet, and other esoteric links used internally on large public networks have larger MTUs but they have routers on each end that fragment larger packets in any case, and on top of that no ISP out there accepts jumbo Ethernet frames if they offer gigabit handoffs.

For posterity, heres the exact sequence I used to back-rev:

1) Open administrative command prompt  (run cmd as administrator by right clicking the cmd icon and selecting run as administrator)

2) pin-reset the switch for 30 seconds

3) At command prompt issue:

C:\Users\tedm>netsh interface ipv4 show subinterfaces

got back:

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 5666836 Loopback Pseudo-Interface 1
1300 1 3809710955 823795215 Wi-Fi
1300 5 0 0 Bluetooth Network Connection
1300 5 0 0 Local Area Connection* 1
1300 1 5268 220312 Ethernet
1300 5 0 0 Local Area Connection* 2

issued:

C:\WINDOWS\system32>netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

got back:

Ok.

issued: 

C:\WINDOWS\system32>netsh interface ipv4 show subinterfaces

got back:

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1300 1 0 5756136 Loopback Pseudo-Interface 1
1300 2 3810708325 824182678 Wi-Fi
1300 5 0 0 Bluetooth Network Connection
1300 5 0 0 Local Area Connection* 1
1500 1 14104 306343 Ethernet
1300 5 0 0 Local Area Connection* 2

accessed switch with web browser.

Did firmware downgrade

After switch responded did pin-reset on it again

At command prompt issued:

C:\WINDOWS\system32>netsh interface ipv4 set subinterface "Ethernet" mtu=1300 store=persistent

got back 

Ok.

exited command prompt and accessed the switch by web browser.

Lastly, my apologies for anyone offended.  My irritation is with Netgear's programmers and paid testers because they are paid to test for this sort of thing.  Sorry to yell at you guys!

[schumaku]

Errare humanum est, perseverare diabolicum,

Many people here agree the idea to "fix" this MTU - without any reasonable support by the stack to handle - was ridiculous at least. I'm just yet another user here, so I'm fine.

[Bockeman]

@tmittelstaedt Thank you very much for politely and informatively exposing this problem and for your clear warnings. Bravo.

I too ran into problems when I upgraded one of my GS108Ev3 switches (from V2.06.03 to V2.06.24). I had been experimenting with VLAN and was getting some unexpected behaviour, so an upgrade seemed the obvious thing to try.

The documentation appears to suggest that following the upgrade, the GS108Ev3 switch would reboot itself.  But I was left with web page still showing the "Transfer Status" with the progress bar filled 100% for half-an-hour.
I would expect at least "after 5 minutes then refresh the page ..." or whatever.
And when this is fixed, then "Tranferring" could be corrected to "Transferring".

So despite the warning not to, I did everything the above instructions tell me not to do. But I could not get access to the device UI.

---

@tmittelstaedt wrote:

As it turned out, yes this was the problem. Unknown to me the MTU on the Ethernet interface on my laptop was set to 1300."

---

Ditto (on my desktop)!

Days later and after much consternation, I came across your warning. I fixed the MTU on my desktop following your instructions.  I now have web access via the device UI.

[schumaku]

It's almost a wonder Netgear engineering managed to implement a very simple IPv4 stack on the 8051-class Micro-Controller along with the still available NSDP. This does also not allow a sophisticated Web UI implementation. The limitations were discussed and explained several times already:

- no PMTUD (Path MTU Discovery), only he default 1500

- no frames different from the default standard 1500 (== no config access over VPNs or similar)

- no tagged VLANs for the configuration management (neither in the WebUI nor in the NSDP)