NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Bad update on 8 port Gs108eV3
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 webs...
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.
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!
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
