So great news everyone, OpenVPN and the TUN/TAP driver is working on Haiku! While this is great news for the development of the project, I need to temper it with some problems that the project has encountered now. So first thing that I had to change first was going from TUN to TAP since OpenVPN wanted a Point-to-Point connection for the TUN driver and Point-to-Point isn’t quite a thing on Haiku yet. I had a lot of trouble with routing with TUN, so I moved onto TAP, and that seems to work… sort of. The main thing is that Haiku can be a client fine but it has some trouble being a server as OpenVPN can set the server up, and have a client OpenVPN connect to it (let us say the client is running Linux), but the client cannot ping the Haiku server. When I try to ping the server, ping will just say Destination Host Unreachable. Looking further into it using tcpdump, I realized that the client is trying to send ARP request to try and find the server and the Haiku server isn’t responding. Checking the Haiku side of things, I noticed that it wasn’t receiving the ARP requests to begin with so I have a hunch it might be the VirtualBox NAT Network I am using but I am not ruling out the possibility of the TAP driver or the TAP interface.
A quick question, I am testing with Indy10 on Lazarus, specifically (for example) with test project idHL7 which creates a client and server and tries to communicate with each other. This works nicely on Windows, Linux, but not haiku (tested x64).
From the test event messages written at the bottom of the testapp window, it looks like cliënt messages work, but not server messages.
Also I am testing with our companies app, which fully works ok, except for its Indy10 tcp server. A client on i.e. windows can connect to the server, but the server is totally unaware (no messages come through to it).
Linux arm and x86, and windows x86 and x64 are all ok.
Would be cool if this apparantly haiku specific problem could be solved …
Btw this problem exists for some years already at least.
Again, don’t know if this would be of any help or if it’s the same problem. I just thought I’d mention it.
So this is normal, on haiku only the first line (Clientconnect) appears.
Oh yes; in order to compile you will need to add a few missing defines in Indy, I think ipv6 specific by heart in files idstackconsts.pas and idstackunix.pas. these should be known in haiku but apparantly aren’t.
Regarding openvpn using 100% CPU: normally, for an application to not use 100% CPU, it should be waiting on something. In the case of OpenVPN, it would be waiting on incoming and outgoind network traffic, and when there is no traffic, it should not need any CPU at all.
That wait will usually happen in read() or select/poll() and it is up to your TUN/TAP driver to achieve it, for example by waiting on a semaphore or a condition variable.
By running OpenVPN through strace, you can see everytime it calls read(), and how fast the call return and with what value (number of bytes read, or error code). WitH that info it is u ually possible to undestand what is happening in the driver, and why the blocking/waiting does not happen as it shculd.
So I can see when OpenVPN is reading since it has a verbose output, also added some debugging lines :p, but the difference with those read calls, when it calls the driver, is that OpenVPN wants the driver to be non-blocking. So I know that it calling read constantly is defined behavior even when I look at how it runs on Linux. I have already made changes to the driver to support the IOCTL call that makes the driver non-blocking, though another way to solve this could possibly be making my own definition for how open, close, read, and write behaviors should act on Haiku which might solve this issue. However, I am currently dealing with the more pressing matter of the OpenVPN server not working on the OS. The hope is that once this gets done I can move onto the other problems but we shall see
