Enable Jumbo Frames Causes External Hostname Problem

krylon wrote:

Pinging the internal IP of the router and the external IP of the router both fail with -f -l 8972. I'm not really surprised by this at all. If I ping my external address from within the LAN it will respond to the ICMP, even though I've asked it not to. The ping fails when outside of the LAN, as expected. I'm not convinced that the router is the problem and I'll try and explain this again :) If I run a webserver on a spare PC with Jumbo Frames enabled, on the same switch, same router (and configure the port forward to the spare computer instead of the NAS), then I can use the external address on the LAN with jumbo frame enabled clients. The same configuration fails on jumbo frame enabled clients when I host the webserver with the NAS with jumbo frames enabled. However(!), when I am outside of the LAN, at the office for example, then the external address will work with jumbo frames enabled on the NAS, but when I get home then it fails on the LAN.

Well, if your client sends a jumbo frame, it certainly will fail to pass through your router (either from inside or outside). You've already proven that with your ping test.

Part of the analysis here is to figure out if the browsing to your PC web server actually uses packets > 1500 bytes. You seem to be assuming that it is doing that, simply because JF are enabled However, it is not that simple. If your PCs always sent >1500 byte packets simply because the interface allows them to, then you wouldn't be able to browse the internet at all - since the internet certainly does not carry JF.

The NAS attempts to sort out if JF are actually available on the connection. I suspect that negotiation isn't working correctly in your scenario - that is it is trying to send a JF, and it isn't getting through. Also, I am thinking that the PC web server simply isn't using them. One way to test this is by installing wireshark on the PC. The trace is complex to understand, but it should be pretty easy to tell if you are receiving/sending packets > 1500 bytes when you connect to frontview via the local LAN connection.

Are you seeing enough performance gain from JF to make pursuing this worth the bother? Also, the failure case is pretty narrow - you can connect via internal IP at home, and external IP on the road. It only fails when you try to connect with external IP at home, which is a nuisance but can be avoided easily enough.

StephenB wrote:

krylon wrote: Pinging the internal IP of the router and the external IP of the router both fail with -f -l 8972. I'm not really surprised by this at all. If I ping my external address from within the LAN it will respond to the ICMP, even though I've asked it not to. The ping fails when outside of the LAN, as expected. I'm not convinced that the router is the problem and I'll try and explain this again :) If I run a webserver on a spare PC with Jumbo Frames enabled, on the same switch, same router (and configure the port forward to the spare computer instead of the NAS), then I can use the external address on the LAN with jumbo frame enabled clients. The same configuration fails on jumbo frame enabled clients when I host the webserver with the NAS with jumbo frames enabled. However(!), when I am outside of the LAN, at the office for example, then the external address will work with jumbo frames enabled on the NAS, but when I get home then it fails on the LAN. Well, if your client sends a jumbo frame, it certainly will fail to pass through your router (either from inside or outside). You've already proven that with your ping test. Part of the analysis here is to figure out if the browsing to your PC web server actually uses packets > 1500 bytes. You seem to be assuming that it is doing that, simply because JF are enabled However, it is not that simple. If your PCs always sent >1500 byte packets simply because the interface allows them to, then you wouldn't be able to browse the internet at all - since the internet certainly does not carry JF. The NAS attempts to sort out if JF are actually available on the connection. I suspect that negotiation isn't working correctly in your scenario - that is it is trying to send a JF, and it isn't getting through. Also, I am thinking that the PC web server simply isn't using them. One way to test this is by installing wireshark on the PC. The trace is complex to understand, but it should be pretty easy to tell if you are receiving/sending packets > 1500 bytes when you connect to frontview via the local LAN connection. Are you seeing enough performance gain from JF to make pursuing this worth the bother? Also, the failure case is pretty narrow - you can connect via internal IP at home, and external IP on the road. It only fails when you try to connect with external IP at home, which is a nuisance but can be avoided easily enough.

My spare PC that I run the test webserver on does use Jumbo frames. If I have jumbo enabled on the spare PC and use it as a client, then I can't access the NAS webserver using the external hostname. If I disable jumbo on the spare PC, I can access the NAS using the external hostname. If I host the webserver on the spare PC, I can access it from other clients with or without jumbo frames using the external hostname, so I know it is the NAS. dsm1212 said that he has the same problem so something is up with the ReadyNAS configuration.

I think we are talking past each other. I am not disputing your tests results - just trying to point out that just because JF are enabled on the PC doesn't mean that the web server is sending (or receiving) jumbo packets for the web pages you are browsing.

StephenB wrote:
I think we are talking past each other. I am not disputing your tests results - just trying to point out that just because JF are enabled on the PC doesn't mean that the web server is sending (or receiving) jumbo packets for the web pages you are browsing.

Thanks StephenB I see what you mean and I agree. This problem is a real quirk but at least I'm not the only one! Hopefully Netgear can help dsm1212 and I on this one since we have the same symptoms.