Blame

6f02e7 Samuli Seppänen 2025-01-29 06:40:08 1
# Community Get-Together
2
3
A few community get-together options were discussed on the IRC earlier (17th Aug 2011):
4
5
- Long weekend in a major European city (e.g. Vienna) during October-November
6
- Next FOSDEM (spring 2012)
7
8
# Development
9
10
## Next Releases
11
12
- OpenVPN 2.2.1
13
- OpenVPN 2.3
14
15
## SVN Merger
16
17
Dazo made a [heroic merge](http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e47fb603ed721bb718495e6f8ed42ec134da2f98) of James' SVN branch to "master". We need to discuss this in more detail. Here are comments from cron2:
18
19
```plaintext
20
Random ramblings in the order I go through things...
21
22
- I git-clone'd openvpn-testing.git, went to the svn-merger branch, and
23
ran "make check" (on Gentoo Linux), with my full-featured t_client.rc
24
setup.
25
26
Test ran:
27
- p2mp tun udp (ipv4 + ipv6 ok)
28
- p2mp tun tcp (ipv4 + ipv6 ok)
29
- p2mp tun udp, "topology subnet" (ipv4 + ipv6 ok)
30
- p2mp tap udp (ipv4 ok, ipv6 fails, known issue with IPv6 auto-conf
31
on TAP, not related to the svn-merger)
32
33
so the client code (at least) is still working as well as my tests
34
cover the code.
35
36
- code alignment needed: for IPv4, the "did_redirect_default_gateway"
37
and "spec.remote_endpoint_defined" have been converted to flag bits in
38
route_list-iflags, but for IPv6, the old structure elements
39
remain - so to make the code more "in-line" for IPv4 and IPv6, this
40
needs code adjustments in the IPv6 code.
41
42
- I'm not overly happy about the "default-gateway block-local" changes -
43
this is less a code issue (the code might be fine) but a procedural
44
issue, with a huge change to route.c coming in without any sort of
45
review or discussion. Gah. (No response needed).
46
47
- I'm somewhat more annoyed by this one (route.c, line 1280):
48
49
#if defined(TARGET_LINUX)
50
#ifdef CONFIG_FEATURE_IPROUTE
51
/* FIXME -- add LR_MATCH support for CONFIG_FEATURE_IPROUTE */
52
53
this is implemented only for the "non-iproute2" case, so we have
54
differing behaviour for iproute2/non-iproute2 compiles now.
55
This MUST be fixed for 2.3
56
57
- implementations of LR_MATCH for most other platforms are missing,
58
but this is something that can be documented in the release notes,
59
and if someone thinks they need this, they can add it - but having
60
support-or-not for Linux, depending on --enable-iproute2, is a no-go
61
62
- the merger has PF_INET6 blocks, and I currently don't run tests over
63
IPv6 transport. So maybe jjo could also take a look at this branch
64
and see whether his stuff is still working.
65
66
- the web view of route.c, "-887,13 - +894,10" looks a bit weird,
67
with "++add_routes (...", but the code in the branch is fine.
68
69
- there's a functional and potentially-fatal change here:
70
71
void
72
-delete_routes (struct route_list *rl, const struct tuntap *tt, unsigned int flags, the struct env_set *es)
73
+delete_routes (struct route_list *rl, struct route_ipv6_list *rl6,
74
+ const struct tuntap *tt, unsigned int flags, the struct env_set *es)
75
{
76
- if (rl && rl-routes_added)
77
+ if (rl-iflags & RL_ROUTES_ADDED)
78
79
this new code does not check whether "rl" is non-NULL, but in theory
80
it could very well be NULL if we only have IPv6 routes.
81
82
So route.c line 1034 should really be:
83
84
if ( rl && rl-iflags & RL_ROUTES_ADDED)
85
86
and the corresponding code in add_routes (route.c, line 990) should
87
read:
88
89
if ( rl && !(rl-iflags & RL_ROUTES_ADDED))
90
91
... enhancing my tests to add a "--route-nopull --route-ipv6 test"...
92
and indeed:
93
94
./t_client.sh: Zeile 200: 8787 Speicherzugriffsfehler ./openvpn $openvpn_conf $LOGDIR/$SUF:openvpn.log
95
96
*bang*
97
98
redirect_default_route_to_vpn (rl=0x0, rl6=0x80f801c, tt=0x8101f90, flags=0,
99
es=0x80dc860) at route.c:811
100
811 if (rl-flags & RG_ENABLE)
101
102
a proper patch is attached...
103
104
- ssl.c: it would be useful if andj or d12fk could review that - I'm not
105
actually sure I understand what changed, but it seems to be some
106
shuffling around of code and #ifdef ENABLE_CLIENT_CR, without actually
107
changing much.
108
109
the rest looks ok-ish to me... (but yes, I can understand that it took
110
you a heroic effort to merge that).
111
```
112
113
Andj was ok with the merge after cron2's changes on #openvpn-devel:
114
115
```plaintext
116
Ok, I can't find anything horrifying in those patches. By just looking at them (that's only ssl.c and ssl.h).
117
```