Hi Lev, 2014-10-07 20:50 GMT+02:00 Lev Stipakov <lstipa...@gmail.com>:
> Patch works great, thanks! I have rebased it a bit and added support > for client-connect plugin call. > Great to hear that my patch works for you! I've finally rebased the patches too, due to my current users complaining about the old OpenVPN version and missing security updates. (See https://github.com/fknittel/openvpn/tree/feat_deferred_client-connect - there's a branch for master and a branch for the OpenVPN 2.3 stable branch.) You say that you've added support for the client-connect plugin call. May I ask what was missing? I'd definitely be interested in any changes you needed to make it work. I would have expected the patch titled "client-connect: Add deferred support to the client-connect plugin v1 handler" to provide everything, but as I only ever used the script handler, it's not unlikely that I missed something. I would like to offer a related feature (and implementation) I call > async-push. > > Use case: authentication / authorization takes time. I have auth/az > code in auth-user-pass-verify and client-connect calls, and sometimes > it takes more that second to execute those. The problem is that after > auth-user-pass-verify is done, OpenVPN server won’t proceed with > client-connect unless some timeout/io event happens for that client. > Also, server will not notify client that client-connect returned > success unless client sends PULL_REQUEST. Client, in turn, sends > PULL_REQUEST one second after connection initiation and after that > once per 5 seconds. So, for example, if at the moment when first pull > request has arrived, client-connect has not finished yet, we will have > to wait another 5 seconds for the next PULL_REQUEST. > So this is basically about replacing a 5s poll-interval with something that should proceed near instantaneously, correct? > Solution: Inotify. Since OpenVPN creates itself files (auth-contro and > client-connect-deferred) which names it passes to the plugin, we > create one inotify descriptor for event loop and right after creating > those files, we add inotify watch on those. Before calling epoll (or > whatever we use) we add inotify descriptor to the list of watched > descriptors. We also keep watch descriptor and multi_instance in a > hashtable. > > When epoll informs us that an event has happened on inotify > descriptor, we get multi_instance by watch descriptor (fetched from > poll event) from our new hashtable and call multi_process_post for > given multi_instance. This will check result from the file and > eventually call multi_connection_established, from where we call > send_push_reply. > > Since implementation uses Inotify, it will work on Linux only. Code is > under #define, which is set at compile-time (--enable-async-push=yes). > > I have attached an implementation. So far has been working nicely in > my test environment. I would love to hear a feedback from the > community. Is the whole thing done more or less right? Any bugs got > introduced that someone could spot? > Thanks for sharing! I'll have a look at it, when time permits. Though my focus is currently on getting some or all of the patches from the basic patch-set upstream. Cheers Fabian
