This is organized by Gert Döring (cron2) and sponsored by Spacenet AG ([http://www.space.net/](http://www.space.net/)).

We have space for about 10 people in the conference room I have booked so far, so I'd limit this to "active developers that are also regularly contributing to #openvpn-devel or the mailing list". If there is overwhelming interest, I can get a larger room, but then the address listed below would change (still in Munich, but not as centrally located).

| Name | Topics | Arrival | Departure |

|-----------------|---------------------------------|-------------------------|--------------------|

| Gert Döring | no particular topics | Fri morning-ish | Sun, late night |

| David Sommerseth| auth/kerberos, plug-ins | Fri 14-ish (SK4759) | Sun, afternoon (LH2456) |

| Samuli Seppänen | openvpn 2.4/3.x, community site | Thu, morning (BT221) | Sun, afternoon (BT224) |

| Steffan Karger | AES-GCM, Windows service review?| Fri, around noon | Sun, afternoon |

| Adriaan de Jong | tbd | Fri, around noon | Sun, afternoon |

| Arne Schwabe | timeouts in OpenVPN | Fri, train, 11:30 | Monday, morning, train|

| Jan Just Keijser| Win7+ integration, performance | Sat morning | Sun, afternoon |

| Heiko Hund | interactive service, NTLM patches, GOST | Fri. morning | Sun. evening |

| Lev Stipakov | peer-id patch, tbd | Thu. evening | Sun. evening |

| James Yonan | OpenVPN protocol changes | Thu. morning | - |

We'll meet in one of the office locations of Spacenet. The address is:

See [Google Maps](https://maps.google.de/maps?q=Landsberger+Stra%C3%9Fe+155,+M%C3%BCnchen&hl=de&ie=UTF8&ll=48.139892,11.526031&spn=0.002957,0.003358&sll=48.917413,11.407993&sspn=4.216739,6.877441&oq=landsb&hnear=Landsberger+Stra%C3%9Fe+155,+Laim+80687+M%C3%BCnchen&t=h&z=18). The entrance is in the upper left corner on the inside of the "#" formed building.

Inside the "#", there are 4 entries in each of the corners, marked as "Haus 1" to "Haus 4". Take the entry "Haus 4". There is a reception for Cable&Wireless and SpaceNet there. Tell the security guy that you want to visit SpaceNet, and he'll call me or one of my colleagues and we'll pick you up (SpaceNet is on the 1st floor of Haus 4). The guard will require some sort of deposit - ID card, driver license, etc - to ensure people properly check out at leaving.

This location is easy to reach by car or by public transport (Tram from central station).

Specifically:

* if you arrive by plane, take S-Bahn S1 or S8 (it's a circle, S1 goes left, S8 goes right) and exit after about 45 minutes at "Hirschgarten" or "Donnersbergerbrücke". About 10 minutes walk from there, or take the Tram 18/19 for the remainder.

* if you end up near the central station (either arriving by train, or with the S-Bahn), exit the central station on the south side, take Tram 18 or 19 towards Willibaldplatz / Gondrellplatz (westwards), and exit at "Lokschuppen". Landsberger Strasse is the street the Tram travels, 155 is across the street next to the "Bauhaus" market

* if you come by car, parking in the vicinity is a bit problematic. You can park in the "Bauhaus" garage but that's "for their customers only", so you'd need to relocate to the SpaceNet parking garage when the SpaceNet crew has left (no guest parking there, unfortunately). We'll find something.

If you get lost, call me: +49 177 2160221

The hackathon will take place from Nov 14 (Friday), 2014 to Nov 16 (Sunday). The room is ours for the full 3 days, and I (cron2) will be there at Friday 09:30-ish. I have no confirmed arrival dates from anyone else yet...

I'll sponsor soft drinks, snacks and the conference room, and I'll sponsor a "Weisswurstfrühstück" for Saturday (see [Weisswurst](https://en.wikipedia.org/wiki/Weisswurst)).

Friday evening, we meet at [Cafe Westend](http://www.cafe-westend.com/) (19:00 local time, table reserved for "Döring"), sponsored by OpenVPN Tech. Good TexMex and local food.

Saturday, it's [Wirtshaus am Bavariapark](http://wirtshaus-am-bavariapark.com/) (19:00 local time, table reserved for "Karger", I assume), sponsored by FoxIT. Bavarian food, beer :-)

So what is the goal of the Hackathon?

* meet in person, talk about things

* contributors agreement (CLA) for OpenVPN 3

* future development of 2.x and 3.x

* GPL violation on multiple apps on the play store

* hack on the 2.4 codebase - there's a number of "large" things we could try to tackle

* peer-id patch set (full support in 2.4, client-side support in 2.3)

* new data packet format proposed for AEAD and "null-compression"

* fix compilation of "master" on windows

* openvpn interactive service - get code in git tree

* async plugin patch, inotify async auth patch (Lev)

* IPv6 gateway detection?

* work on open trac issues

* lots of things to review and bugs to fix

I'm all open for additions here - I think the meetings in Brussels and Munich 2013 have shown that "just being able to sit together and hack" is a useful exercise.

Of course, there will be free WiFi available, and for bandwidth junkies, wired Internet as well :-) - Spacenet is an Internet service provider, and that's one of their core locations, connected with multiple 10Gbit links to the world...

* "Motel One Munich City West" has been recommended as "being close, reasonably priced, and generally OK"

This is just a sort of unordered list of things we agree on, to avoid thoughts getting lost

* drop Windows XP support in OpenVPN 2.4

* this also affects Windows Server 2003 (extended support) and Windows XP Embedded

* specifically: XP will not get "interactive service" support, because the APIs used for IPv6 routing are not available on XP

* 2.3.x will continue to be supported

* 2.4.x might drop XP support if supporting it gets too hard, like "keep all the netsh calls in there" - it will be announced in the 2.4.0 release notes "use on your own risk, but not officially supported anymore"

* functionality that will fail on XP and older will be wrapped in an #ifdef

* strip out the PRNG support from OpenVPN, as both SSL libraries have good PRNG inside, and at least PolarSSL's is faster (syzzer)

* about removing snappy support - we keep it for the time being (#ifdef), because OpenVPN 3 and OpenVPN AS support and use it. Since compression can be negotiated, we can just leave it off for platforms where it is complicated to build (like Windows due to the libstdc++.dll being so big)

* coding style in OpenVPN source - see [Bikeshed](http://blue.bikeshed.org/) and [Indent style](http://en.wikipedia.org/wiki/Indent_style) - candidates: Allman, GNU, K&R (higher git impact when changing over due to the opening bracket moving), and then tabs/no-tabs.

* everybody is "okayish" with changing, as long as it is done consistently, everywhere

* slightly stronger feeling for Allman style - **Allman style** it is

* syzzer volunteers to make the non-consistent files consistent

* "the big whitespace change" for existing code happens at 2.4-RC, and then we will no longer do "patches to master and 2.3" (which would have different indentation) but to "master and 2.4" (same style), except for critical issues, which usually are small and manageable

* line length?

* "stick to what we have for now", do not reformat arbitrarily

* breaking a line in the middle: align to opening (round) brackets in line above

* tabs vs. spaces: "not mixed"

* majority for "only spaces, no tabs"

* this is what we change to: all spaces

* new packet format? (Mail from James, Message-ID: <54648EAC.70204@openvpn.net>)

* AEAD: 12-byte nonce is needed - use session ID plus HMAC random for that? James and Syzzer agree on that.

* compression V2 format - yes, go for it

* to support COMPRESS_V2 the server needs to actually send the peer-id packet format as well (right now only the client sends peer-id packets)

* discussion:

* James: let's actually negotiate COMPRESS_V2 so we do not couple peer-id and compression which is actually independent parts/layers of the code

* Arne: this could be "PACKET_FORMAT_3" (peer-id+compress-v2)

* James: lean to "negotiate compression and packet format independently, as they are different layers"

* Jan Just: nice thing about scalar packet format is that you **know** which features have to be in there - but "don't do too many of these versions"

* discussion ended up with crypto negotiations, but I think we'll just see a patch from James with "whatever will be the outcome" for COMPRESS_V2

* regarding --enable-ssl/disable-ssl - decided to a) ask the openvpn-users whether there is anyone using OpenVPN without SSL, and if not, remove the option (so --enable-crypto would bring SSL, --disable-crypto would take away SSL and all crypto) - one different #ifdef variant less

* timeouts on client connect (Arne)

* we have various timeouts in the client - socket timeout, proxy connect timeout, tls handshake timeout

* master timeout - if connect does not succeed in that time, go to next <remote>

* goal: only have "master timeout", get rid of individual timeout bits

* "server poll timeout" -> must receive at least "some answer" in (short) time, to decide whether server is alive at all. Total handshake needs to be much longer (slow CPUs, etc.) --> short timeout to skip over dead servers / dead networks, longer "master timeout" to handle whole setup

* James: please keep server poll timeout, and keep that short (4s-ish) - the rest could be integrated unless there is a reason to keep them separate

* feature-ACK: remove all the individual timeouts and replace by "server poll timeout" that is "up to the first packet coming back from the server". If nothing is configured, current default is "0" = "no server poll timeout" - new default: 60 seconds to mimic existing TCP connect timeouts, plus log notice ("if we have multiple remotes and no server-poll-timeout, user experience might be better setting this to a lower value, like 5s").

* inotify patch from Lev (on list) - feature discussion

* this is about async authentication plugin (deferred authentication)

* "response from plugin" is delivered by the creation of a file

* currently, we stat() in regular intervals -> replace by inotify so system load is lower

* it's done via a single file descriptor that is added to the master poll() in the event loop which will tell you about an arbitrary number of files that are watched

* portability?

* feature-ACK so far ("generally OK"), patch needs review

* async-plugin patch

* used in production at Lev's servers since some months and Fabian Knittel's server

* enables async handling of client-connect script and plugin

* -> openvpn is not stuck while client-connect script does "slow things" (like, radius start records taking 300ms)

* impairs performance on busy servers

* David looking into patch, on the mailing list - whitespace changes, not easy to read

* "someone needs to talk to Fabian to rebase to master"

* there is general interest in the feature, but we need to find time!

* performance (general performance, and Windows in particular)

* throughput is worse than "Cisco Connect" client (2-3x - David can reproduce it at will to server side)

* might be related to socket buffers - please test setting to 256k or more

* jjk: throughput is not crypto-bound, is "networking" (latency/buffers?) - can be reproduced with "cipher none"

* windows performance is way lower even (factor 5!)

* jjk: we need to measure this in a more controlled experiment ("I am a physicist" - cron2 agrees)

* to sum up: jjk "has the equipment" (will run baseline on Linux)

* log file seems to suggest packets receiving out of order --> **check that**

* experiment with socket buffer options

* James will check with Thomas Divine whether he has an idea on Windows performance

* upload speeds via VPN to David's servers in RedHat VPN seem to be limited by RedHat internal lines...

* future plans? mid term, long term?

* 2.4 (mid-term goals for 2.x)

* interactive service! MUST HAVE

* timeout stuff fixes (Arne)

* peer-id MUST HAVE

* inotify "good chance", async plugin "depends on time"

* IPv6 gateway handling - really should go in, but cron2 has no time :( - depends on how the remaining schedule surrounding 2.4 goes

* AEAD/GCM - code is there, not performing nicely yet - MUST HAVE

* EC with external keys is not working yet - "nice to have", nobody working on it, not actually hard, just "many small pieces to touch"

* new data packet format (COMPRESS_V2)

* NTLMv2 proxy fixes (in 2.4.0 and 2.3.x, please - bugfix!)

* new windows installer for gui and everything (mattock), fixes lots of bugs, should be in 2.4.0 - MUST HAVE

* rough timeline: march 2015 for 2.4.0-RC?

* coding style change right before 2.4.0-RC

* improve systemd support (patches on the list)

* --enable/disable-ssl -> remove #ifdefs

* get rid of "useless #define" - find your pet peeve, ask on the list, send patch if feature-ACK

* look at trac

* auth-user-pass inline (patch from pekster?) - status? followup on it?

* GOST (nice to have, but no pressing need now - Heiko to rebase to master, overlap with AEAD for "newer openssl APIs"? - look at it)

* 2.5 (long term goal for 2.x)

* multiple server sockets (TCP+UDP)

* multiple threads ("however it might look like in the end"), depending on the performance bottlenecks discovered

* improved testing framework (andj) - MUST HAVE, some stuff might go to 2.4

* isolate functionality better (no central context everywhere, gets into the way of testing) (syzzer)

* better document internal API and wire protocol - go for a (personal) RFC? (syzzer/james)

* cipher negotiation

* 3.0 (mid term and long term)?

* today: solid client (iOS, Android)

* work being done on adding server functionality

* James feels more comfortable about "putting it out to the public" when it has (basic) server functionality

* CLA issues still open - current state: discussed inside OpenVPN Tech, "nearly done"; similar to Google CLA for Android

* 3 being used as a testbed for new ideas

* James: "I've watched python 2 to 3 disaster, learned from it" - on the wire protocol will be 100% compatible, most client config stuff is compatible

* Andj: splitting community resources is tricky, James agrees

* Heiko: it would be nice to have a "cli wrapper" that presents the same cli + mgmt interface to "GUI users" (like Tunnelblick, etc.)

* James: agree, mgmt interface would be good

* Arne: I can push an Android version with my gui, if James is comfortable with it - James: "when I'm comfortable with the code, still very much refactoring going on, so wait for the server functionality to be done"

* Andj: multithreading? James: it's sort of thread-agnostic, but there is no active multithreading functionality yet

* multi-socket server is actually very easy, as you just create a few ASIO socket objects and listen to them (and it's **fast** too!)

* weekly community meetings: **new time** Monday, 20:00-22:00 European local time, make it more frequently again - first meeting: Monday 21st