Where We Last Left Off
So last time I posted I was able to say that I got the client side for OpenVPN on Haiku working but not the server but I am proud to say that now both the server and client work extremely well now on Haiku :) I was able to get the server from not working to working and was able to get the latency for the entire VPN operation down from 1000ms average to anywhere between 2ms to 9ms (that’s a caveat as that is without blocking which will be discussed later). I had a check in my tun_read() function wrong where I wanted any side that is non-blocking to send a signal to the other side’s condition variable that something is now in their queue but had it backwards with a not statement in there. The simplest mistakes slip the mind huh :p Anyway, the server also follows suit with the faster latency so now that the read and write functions are basically complete, lets get on with what I was dealing with for the past 2ish weeks.
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev57127 through hrev57183.
Project status overview
The long awaited stateful FD monitoring has finally been
implemented on Haiku, and there now is a partial implementation of kqueue usable in libbsd.
Therefore, Release builds of .NET can now work properly (after some more hacks) and have been set
as the default in my custom dotnet-install.sh script.
Due to some technical difficulties in parsing Doxygen documentation and converting it to the XML
format used in C#, I have delayed my effort to generate documentation for the Haiku API bindings.
Instead, I am going to resume my effort of bootstrapping .NET on Haiku, as mentioned in my
second report.
Tempered Optimism
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.
The Weekly Problem
So we are just past the midway point for GSoC and last update I told you guys that I had a working (albeit somewhat buggy) TUN Driver working. I had gotten great feedback from Pulkomandy, Axel, and Korli to help with a more efficient driver and to make it more human-readable because it made no sense the way I had written it. I have very good news to bring to everyone in that all of the 3 main problems that I talked about last time are all solved! I think most of them got solved after I fully understood creating semaphores and imposed execution order by adding a write semaphore. While this new code made the driver much more efficient and less error-prone, there were two new errors that popped up during testing:
Project status overview
C# bindings for some parts of the Haiku API is now available, along with basic .NET SDK support for
building Haiku applications, in a .NET workload (more details below). The source code and install
instructions are currently in this GitHub repo.
.NET custom builds for Haiku are still regularly
updated to reflect the latest changes in both .NET and Haiku. Most recently, the datagram socket
hack has been removed as SOCK_DGRAM support for Haiku has been merged.
Sorry for the late blog post everyone! Personal life and some roadblocks on the project got in the way but I am proud to say that the driver is up and working!
Problems, Problems, and more Problems
I got the semaphore problem settled, but I then ran into a problem where the data that the application on the interface side sends a packet was then not receiving the packet. Through some debugging I found out that the interface, when it goes into device_consumer_thread for getting the receive function, it fails here. Looking deeper into when that interface->receive_funcs element gets assigned I found the function here which I realized is never called when I call ifconfig to set up the interface. I ran into the solution to the problem by just changing the type of datalink frame from loopback to an ethernet frame that the interface will be using from now on. That brought the packet to an interface and I started to get a new problem of course :)
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev57061 through hrev57126.
Argument handling on Haiku
Hi, I’m Nephele. I’ve not made a blog post before, but this seemed like a good opportunity.
There are two main ways to start an application from Haiku’s UI, directly and indirectly.
Directly by opening it, and indirectly by opening a file that the application you want supports (and is configured to handle).
The indirect way involves opening a file that the application supports and having the mimetype plus the registrar figure out where to forward this to. This can be done by launching a new application or by forwarding it to a running application via a BMessage.
(This is also how “open” in the Terminal works, it will open each argument as a document to open. Unlike xdg-open this supports opening multiple files at once.)
Project status overview
During this period, I have been working to get the Release build of .NET SDK to work more stably.
I have identified some issues related to POSIX thread scheduling in Haiku in the process. Sadly,
I cannot deliver stable builds of the SDK at the moment because that depends on edge-triggered
file events.
As mentioned on my
forum thread, I have ported some
sample applications of popular C# frameworks such as GtkSharp or FNA. Some other apps are a bit
tricky since they rely on native components. I will not explore these ports as part of GSoC; it is
the HaikuPorts community’s job to port native libraries.
