LinuxQuestions.org - vsftpd reverts to original MTU mid-stream

- Red Hat (https://www.linuxquestions.org/questions/red-hat-31/)

- - vsftpd reverts to original MTU mid-stream (https://www.linuxquestions.org/questions/red-hat-31/vsftpd-reverts-to-original-mtu-mid-stream-599201/)

vsftpd reverts to original MTU mid-stream

On:
Red Hat Enterprise Linux WS release 3 (Taroon Update 5)
Kernel 2.4.21-37.ELsmp on an x86_64
vsftpd: version 2.0.1

I've been chasing a problem of apparently random ftp transfer failures. In this case the vsftpd is pushing a file to the client. The transfer fires up and the router notifies vsftpd "ICMP Destination unreachable Fragmentation needed and DF set". Vsftpd adjusts the MTU and things are rolling along just fine for a time. In what I can only describe as the "middle" of the transfer after receiving an ACK, the next vsftpd send reverts from an MTU of 1420 to the default of 1500 bytes. The only event I saw that may have triggered this was a new FTP thread that started up about 80 packets earlier and went through a path MTU discovery.

So being a network weenie I'm just trying to speculate where to look next. For instance is there a max_threads that could have caused vsftpd to wrap its session pointer?

Thx

The MTU isn't set by vsftpd - it's done by the kernel network stack.

The behaviour you're seeing, however, is normal. From the MTU discovery RFC:

Quote:

To detect increases in a path's PMTU, a host
periodically increases its assumed PMTU (and if it had stopped,
resumes setting the DF bit). This will almost always result in
datagrams being discarded and Datagram Too Big messages being
generated, because in most cases the PMTU of the path will not have
changed, so it should be done infrequently.

Dave

RFC 1191 revisited

I went back and reread RFC 1191. I see that the application can decide to test the waters with a larger MTU. The inconsistent bit seem to be that Juniper router didn't advise that larger MTU still wasn't accepted with a Destination Unreachable.