Hi Gert, Thank you for the documentation link, I will try to take a look at it when I get some free time from work and life. I think my specific use case is a bit different than other peoples. I think most people run VPN clients directly on their client host machines which means that their host operating system and network stack will honor a lower sized MTU directly before sending network data outbound.
In my use case, I am piping my entire home WiFi network traffic through a dedicated Linux VM running on a Mac Mini which can result in some serious issues if I'm not careful enough. The reason why MTU size (1500 bytes) is important to me is because all of my network clients will auto assume the standard 1500 bytes once they join a network. This means that if my middle network VPN link MTU is <1500, it will likely cause fragmentation issues for my LAN clients which I really don't want performance wise. If the VPN link MTU is >1500, then my ISP will fragment my packets at the router WAN side as that is the network standard there also. In addition, the code base is only performing singular read/write MTU-sized calls and sending them out right away which also greatly impacts potential performance as well. With my modifications made, I can specifically and directly target an exact 1500 byte MTU VPN link so that it correctly matches the LAN and WAN side of the networks which is really important network wise and I can also let TCP at the kernel level beautifully handle huge streams of bulk data and ordering and delivery on my behalf as efficiently as possible. This would be a pretty nice modification if I could make it through to the end. This is one of the reasons why I dislike WireGuard personally. It's at the kernel level instead of application level, it enforces a very small sized MTUs potentially causing fragmentation and performance issues and its UDP based only. :/ Thanks for your time on this, Jon Chiappetta On Wed, Aug 6, 2025 at 7:22 AM Gert Doering <g...@greenie.muc.de> wrote: > Hi, > > On Wed, Aug 06, 2025 at 07:03:51AM -0400, Jon Chiappetta via Openvpn-devel > wrote: > > Is there any development setup guide I could follow in the future which > > would allow me to submit a pull request to the OpenVPN codebase in an > > official manner? > > https://community.openvpn.net/Development/DeveloperDocumentation > > which is outdated in a few places, but the most important thing is > still correct: we don't do Github PRs, we do "patch on list" or "push > to gerrit". > > Before you spend too much time on actual code, it makes sense to see if > there is general agreement on the problem statement, and the direction > to fix it. For problems that we cannot understand, it's slightly harder > to convince us to accept the code (and the maintenance and testing > obligation that comes with each new line of code). > > So far I have heard "MTU mumble mumble" and we do have lots of MTUs of > all sorts already :-) > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
