Here's the summary of the IRC meeting.


Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 2nd May 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex and syzzer participated in
this meeting.


Discussed the obfuscation approach taken by Google's Jigsaw project /
Operator Foundation. The preliminary patches are semi-private, and it
was agreed that they should be modified somewhat before we ask them to
be sent to the mailing list.

Our suggested approach is this:

  - preserve current settings (proto, port, etc)
  - specify --transport-plugin <plugin.so> [params],
    referencing one plugin per connection block
  - plugin needs to be loaded at startup with --plugin
  - 'ops' like approach for required functions (i.e. attached to
    connection block)


Had a discussion of the networking API (netlink patchset). The current
WIP API is here:


And how to use it from tun.c:


Some changes were proposed. Ordex will try to implement them by next


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(10:57:29) ordex: mattock: Topic for #openvpn-meeting: Next meeting on 
02/May/2018 at 11:30CET. Agenda at 
(10:57:31) vpnHelper: Title: Topics-2018-05-02 – OpenVPN Community (at 
(12:31:19) ordex: aloha :)
(12:31:23) dazo: Hey!
(12:31:34) ordex: aah! I am not alone!
(12:31:42) ordex: mattock: syzzer: cron2 ?
(12:31:48) syzzer: moin :)
(12:31:49) cron2: I'm alway shere
(12:31:52) ordex: :D
(12:32:04) cron2: at least, electronically... whether my brain is engaged...
(12:32:07) ***cron2 goes checking
(12:32:10) dazo: cron2 .... the spirit of openvpn :-P
(12:32:14) ordex: :D
(12:32:19) dazo: lurking in the corners of the interwebs
(12:32:53) mattock: hi!
(12:33:19) mattock: start from #1?
(12:33:26) mattock: networking API: discussion and high-level review (netlink 
(12:33:26) ordex: actually, I'd suggest to start from #2
(12:33:28) mattock: ok
(12:33:30) ordex: because it's shorter
(12:33:35) mattock: #2 get feedback for approach taken by obfuscation via 
plugin (Jigsaw project) 
(12:33:40) ordex: yeah
(12:33:55) cron2: yeah
(12:34:01) ordex: so basically I went through the patches provided by these 
guys working for Google, that are implementing a obfuscation API for openvpn2
(12:34:09) cron2: where are they?
(12:34:16) ordex: the patches or the guys?
(12:34:17) ordex: :D
(12:34:22) cron2: (sorry, brain is still missing)
(12:34:24) cron2: patches
(12:34:35) ordex: the patches are those that dazo pointed us to in a private 
email some time ago
(12:34:39) ordex: they have not been sent to the ml yet
(12:34:41) cron2: ah
(12:34:45) ordex: I wanted to provide some early feedback first
(12:35:19) ordex: as I Was saying the code is fairly good already so I will 
tell them to go ahead and send to the ml
(12:35:22) ordex: just one question for you
(12:35:34) ordex: the approach they took is as following (high-level):
(12:35:41) cron2: grumble, can't find the mail.  Anyway: listening
(12:36:02) ordex: Subject: "Fwd: Plugin API for Obfuscation"
(12:36:13) cron2: found it
(12:36:23) cron2: was looking for "mails from dazo".  Mail is from davids
(12:36:32) dazo: :)
(12:36:41) ordex: - they have extended the plugin API to include calls for 
establishing a connection and then "mutate/obfuscate" the traffic
(12:36:56) ordex: the way they tell openvpn about this is by means of a special 
(12:37:05) ordex: so instead of specifying udp or tcp they specify "intercept"
(12:37:13) syzzer: oh, I totally missed that patches were already sent :')
(12:37:20) cron2: syzzer: they weren't
(12:37:21) ordex: syzzer: not sent yet
(12:37:25) cron2: 
(12:37:27) vpnHelper: Title: Comparing 
OpenVPN:db34435...OperatorFoundation:rtt-working · OpenVPN/openvpn · GitHub (at 
(12:37:57) ordex: my question for which I just wanted to get some feedback from 
you is about this "intercept" protocol. just wanted to hear is from an 
high-level perspective this looks like a reasonable entry point
(12:38:10) ordex: or if a "transport API" should rather have something more 
(12:38:21) ordex: s/is/if
(12:38:40) cron2: I do not like the word "intercept".  I can live with "a 
specific keyword to 'proto' that states 'let the plugin API deal with all the 
(12:38:53) cron2: OTOH
(12:39:01) dazo: so ... you need --proto intercept + --plugin which supports 
the hooks to obfuscate?
(12:39:08) ordex: dazo: correct
(12:39:33) cron2: maybe it would be nicer to actually stick to "proto udp 1234" 
and add "--plugin-transport-massacre" to enable the plugin
(12:39:43) dazo: how is udp/tcp protocol defined?  By the plug-in?
(12:39:51) cron2: so the "which protocol, which port" bit would still be in the 
openvpn config (= you can find it)
(12:40:00) ordex: dazo: I think so. I think at that point udp/tcp is a plugin 
specific knob
(12:40:17) ordex: cron2: so you know what the plugin is actually using?
(12:40:26) ordex: (i.e. for port forwarding/firewall in general)
(12:40:33) dazo: I actually like this approach ... when considering multiple 
--remote / connection profiles
(12:40:48) dazo: it means it can try to connect without obfuscation and with 
obfuscation in the same config
(12:40:52) syzzer: cron2: so what would the "proto udp 1234" in the config mean 
when using the plugin
(12:40:55) cron2: ordex: the plugin can be free to ignore me (like, "always 
connect to some magic wonderbox and hand over credentials")
(12:41:20) cron2: syzzer: it could mean "the remote server is listening on udp 
1234, but expects $pluginmagic not standard-openvpn"
(12:41:52) dazo: I would probably prefer to use the keyword "plugin" instead of 
"intercept" though ... that gives a clearer semantic
(12:42:05) ordex: dazo: yeah, think so too
(12:42:15) cron2: but if I just do "proto intercept", how do I specify where my 
server is?  If I have more than one?  It would have to be "on the plugin line", 
which there can only be one (so, connection retry / failover to next host / ... 
logic would need to be in the plugin)
(12:42:16) syzzer: Ah, yes, I think that could make sense. Considering for 
example the immensely popular "xor obfuscation"
(12:42:38) cron2: syzzer: right.  That would not even have a "connect()" 
method, just "encap/decap"
(12:42:44) ordex: can plugins parse the config?
(12:42:48) ordex: and have their own set of options?
(12:43:02) cron2: ordex: they have their own set of options on the "plugin ..." 
(12:43:03) dazo: you can pass options to plugins ... via the --plugin 
(12:43:12) ordex: ah ok
(12:43:32) cron2: what we would need is to pass "all options that are 
connection-related" to the plugin->connect() method
(12:43:41) cron2: (like, proto, port, v4/v6, proxy, ...)
(12:43:47) ordex: yeah
(12:43:51) syzzer: but that would mean that we'll need to support plugin in 
<connection? blocks...
(12:44:37) cron2: if we go by --plugin cli arguments, yes - and this will be 
(12:44:38) dazo: with the --proto intercept/plugin approach .... we would not 
need to extend <connection/> or multiple --remote lines
(12:45:05) cron2: dazo: the problem with that is "if you want multiple remotes, 
you cannot specify them inside openvpn.conf anymore"
(12:45:43) dazo: yes you can .... --remote server1 1194 udp --remote server1 
11194 intercept
(12:46:22) cron2: dazo: if you have <n-1> without intercept and one with 
intercept, but is that a useful case?
(12:46:41) cron2: like, you want xor plugin.  You have a VPN server provider 
that offers 20 remotes, all with xor.
(12:46:44) cron2: how do you config that?
(12:46:57) syzzer: cron2: as a get-aroundt-the-gfw fallback, that sounds useful
(12:47:25) dazo: right, the plug-in would only support a single set of 
obfuscation parameters, that's true
(12:47:36) cron2: syzzer: yes, but should we design the API in a way that 
that's the only way it can handle multiple remotes?
(12:47:43) ordex: i think what cron said earlier is the "simplest" concept: if 
a plugin implements ->connect(), then we simply pass all the connection-related 
options to it. so they come from the standard --lport, --remote, etc config 
(12:47:44) dazo: but adding support for --plugin within connection blocks .... 
that's not a trivial task
(12:47:54) cron2: so my idea would be like this:
(12:48:05) cron2: - we keep --proto / --remote / --port as it is
(12:48:23) cron2: - we add an option "--transport-plugin-enable <options>"
(12:48:55) cron2: - plugin->connect() gets access to our <connection> options 
plus the <transport-plugin-enable> options
(12:49:08) cron2: and then it can do with it whatever it wants - honour them, 
ignore them, mutate them
(12:49:26) cron2: if --transport-plugin-enable is configured, a plugin MUST be 
loaded that can do, well, transport
(12:49:36) dazo: so --transport-plugin-enable would be given the .so to load as 
well?   Or just the arguments to pass to a --plugin ?
(12:49:43) cron2: dazo: you'd do
(12:49:48) cron2: --plugin mymagic.so
(12:49:50) cron2: <connection>
(12:49:55) cron2:   remote vpn.ca 1234
(12:50:02) cron2:   transport-plugin-enable 0x12345
(12:50:04) cron2: <connection>
(12:50:08) cron2:   remote vpn.us 4321
(12:50:13) cron2:   transport-plugin-enable 0x99999
(12:50:15) cron2: </connection>
(12:50:45) ordex: should we consider loading multiple plugins? or not for now?
(12:50:47) cron2: the "0x12345" number here could be "the xor key", or 
"anything else that makes sense to the transport-plugin in that case
(12:51:18) dazo: multiple --plugin would truly be even more tricky ... you can 
do that already, and they would be chained
(12:51:20) cron2: ordex: we'll have to handle that eventually (on the server 
side, you might want a transport plugin and an auth plugin)
(12:51:44) ordex: in constrained environment, it would be needed to try 
different obfuscations. even though this can be solved with multiple configs 
and multiple servers
(12:52:17) cron2: --transport-plugin-enable myxor.so 0x9999
(12:52:25) cron2: --transport-plugin-enable magicgoogleAES.so 0x1234523414
(12:52:36) cron2: ?
(12:52:51) ordex: I like that, but this is going to be interesting codewise :D
(12:53:00) cron2: ("force use of a plugin with that name, and pass it 
(12:53:07) cron2: ordex: I don't think it will be, tbh
(12:53:22) ordex: oh ok
(12:53:26) ordex: even better :)
(12:53:32) dazo: that's probably a somewhat simpler approach .... doing it via 
--plugin + --transport-pluing-enable would need a massive rework of the 
plugin.c code  (it is currently a for() loop looping over the set of feature 
being requested in the plugin, defined by a "type" mask)
(12:53:32) cron2: if plugins can be chained today (this is how I understand 
dazo), we just need to agree on "do I want a single transport plugin, or 
(12:54:09) cron2: dazo: I do not want them *loaded* in the 
--transport-plugin-enable code, just referenced -- loaded at startup time with 
the normal --plugin call
(12:54:23) cron2: --transport-plugin-enable mymagic.so 
(12:54:51) cron2: would then find that plugin in the list, and set up some sort 
of ->connect(),->encap(),->decap() pointers
(12:55:04) cron2: so we do not need to walk for every packet
(12:55:08) ordex: oh so we'd still need to list multiple --plugin options to 
load them all?
(12:55:20) cron2: since a plugin can provide other features, yes
(12:55:25) ordex: ok
(12:55:27) cron2: so you ave
(12:55:30) cron2: plugin myauth.so
(12:55:34) cron2: plugin eurephia.so
(12:55:38) cron2: plugin myxor.so
(12:55:42) cron2: plugin googlesAESthingie.so
(12:55:44) cron2: and then
(12:55:48) cron2: <connection>
(12:55:57) cron2:   transport-plugin-enable myxor.so 0x1235
(12:56:00) cron2: <connection>
(12:56:04) cron2: ...
(12:56:18) cron2: "I think this could work, and be easy to see in the config 
what is happening"
(12:56:24) dazo: look at plugin.c:814 / plugin_call_ssl() ... this is what is 
being called whenever anything in OpenVPN wants to make use of a plug-in
(12:56:24) ordex: yeah
(12:57:00) dazo: then the real call inside the plugin happens via 
(12:57:29) dazo: but the plugin_call_ssl() need to be extended with a "filter" 
to only run the selected transport plugin, defined in a connection block
(12:58:15) cron2: dazo: or we add something like "plugin_setup_transport()" 
that would find desired transport plugin and setup "fast calls" for 
connect/encap/decap later on
(12:58:48) cron2: but anyway, that is implementation, iff we agree on the 
(12:58:57) ordex: yeah
(12:59:04) ordex: implementation details can be discussed later
(12:59:08) ordex: when the code is on the ml
(12:59:32) ordex: even though an approach in "ops-style" like suggested by 
cron2 would not be bad. so the lookup is done only once
(12:59:45) ordex: anyway, do we all like this per-connection/remote approach?
(12:59:46) dazo: I would actually suggest we provide this feeback back to 
Operation Foundation, so they can consider all this before submitting to the ML
(13:00:18) cron2: dazo: yes (on "feedback before patches")
(13:00:43) ordex: I think we could directly suggest the "ops-like" approach, 
no? but /me is not up-to-date with the entire plugin stack
(13:00:53) dazo: I see the advantage of being able to use different obfuscation 
plugins ... I'm more concerned about the implications it does to the complexity
(13:01:29) cron2: my mental eye sees one extra call per packet ("if 
c->plugin.encap_function != NULL ...")
(13:01:35) cron2: and one extra call per function setup
(13:01:42) cron2: all the rest nicely encapsulated away
(13:01:54) cron2: s/function setup/connection setup/
(13:02:00) ordex: cron2: we could force those ops to be non-null at load time
(13:02:04) ordex: or we reject the plugin (?)
(13:02:15) cron2: ordex: well, we could be running "with no plugin" :)
(13:02:27) ordex: event though some obfscation plugins may not have all the 
APIs implemented
(13:02:39) cron2: (we could certainly have the c->encap_function point to "our 
normal encap function")
(13:02:46) ordex: cron2: well, yeah..in a way or another there must be a check
(13:03:03) dazo: right, but we have the struct plugin which keeps a list of all 
plugins ... so the plugin_call_ssl() can then not be used to for traffic 
obfuscation, it needs a different call ... which should point at the specific 
plugin for the connection profile
(13:03:36) dazo: so it is kind of duplicating existing plug-in code paths but 
at the same time it will be somewhat simpler in other aspects
(13:03:52) cron2: "always do function pointers for encap/decap" is certainly 
the "elegant" way, but it makes the code harder to understand for the normal 
case... (ran into this when trying to figure out setsockopt() failures in 
NetBSD... call chain through 4 or 5 function pointers...)
(13:04:09) cron2: dazo: yes
(13:05:35) dazo: well, plugins depends on function pointers anyhow ;-) ... But 
we should make it as simple as possible
(13:05:40) ordex: cron2: hehe yeah. but if we keep it simple, it should not get 
that bad :P
(13:05:46) ordex: yeah
(13:05:54) dazo: Hmmm ... perhaps the connection block could just carry the 
function pointer?
(13:06:15) dazo: IIRC, connection blocks are used under the hood, even if only 
a single --remote is configured
(13:06:42) mattock: (12:33:26) ordex: actually, I'd suggest to start from #2 
... because it's shorter
(13:06:43) mattock: :P
(13:06:48) ordex: :P
(13:07:01) ordex: dazo: that's probably how it may work..
(13:07:17) dazo: mattock: Murphy's law in practice ;-)
(13:08:24) ordex: dazo: yeah, connection blocks are used also for one remote
(13:08:40) ordex: the remote is converted to a connection entry in the 
post-options-parse thing
(13:09:01) ordex: so some per-connection block field is probably the cleanest 
(13:09:24) ordex: I think I've got enough to get back to them and keep busy for 
a while..
(13:09:24) dazo: so if --transport-plugin is defined, it looks up all loaded 
--plugins and sets the function pointer directly to the obfuscation function 
.... this way, there's less CPU cycles wasted when passing data for 
(13:09:38) ordex: yes
(13:09:50) ordex: this is the "ops-like" approach cron2 described before, I 
(13:10:00) dazo: yeah
(13:10:08) dazo: okay, I'm convinced about this approach now :)
(13:10:10) ordex: this is common in the kernel for FS or network devices too
(13:10:11) ordex: :D
(13:10:12) ordex: goood!
(13:10:25) ordex: i'll forward our comments to them and see what they think 
about it
(13:11:04) dazo: thx!
(13:11:29) ordex: are we good with #2 ?
(13:11:38) cron2: yep :)
(13:11:39) dazo: yeah
(13:11:47) mattock: ordex: if you could summarize our thoughts for me as well
(13:11:50) mattock: for the summary
(13:12:06) ordex: ok
(13:12:09) ordex: let me see
(13:12:11) mattock: thanks!
(13:13:16) ordex: - preserve current settings (proto, port, etc)
(13:13:16) ordex: - specify --transport-plugin <plugin.so> [params], 
referencing one plugin per connection block
(13:13:16) ordex: - plugin needs to be loaded at startup with --plugin
(13:13:16) ordex: - 'ops' like approach for required functions (i.e. attached 
to connection
(13:13:16) ordex:   block)
(13:13:26) ordex: needs to be reworded and extended :P of course
(13:13:47) ordex: but i think these are the major points we touched, no?
(13:14:03) cron2: dazo: commit 23d61c56b9fd218c39ad151b01b7e2d6690e6093
(13:14:10) cron2:     Always use connection_list, simplifies the reconnection 
(13:14:21) dazo: " referencing one plugin " -> "reference the callback function 
in one plugin per connection block"
(13:14:53) ordex: oky
(13:15:12) dazo: cron2: yeah, I vaguely recalled something like that :)
(13:15:26) cron2: this is why I went looking it up :)
(13:15:33) dazo: :)
(13:16:09) ordex: 15 minutes left for netlink :D
(13:16:13) dazo: :-D
(13:16:28) cron2: ok, which is the most relevant patch you want feedback for?
(13:16:39) ordex: I think the networking API per se
(13:16:43) ordex: let me pick it
(13:17:05) ordex: so this is the API I came up with: 
(13:17:06) vpnHelper: Title: [Openvpn-devel,1/8] implement platform generic 
networking API - Patchwork (at patchwork.openvpn.net)
(13:17:22) ordex: and here it is used for tun.c: 
(13:17:24) vpnHelper: Title: [Openvpn-devel,3/8] tun.c: use new networking API 
to handle tun interface on Linux - Patchwork (at patchwork.openvpn.net)
(13:17:25) cron2: *reading*
(13:17:35) ordex: ok
(13:17:52) ordex: the question is: is this "reasonable" so that we can move 
also the other platforms to this API in the future?
(13:18:02) cron2: this is what I'm looking for :)
(13:18:21) ordex: hehe yeah, I think we all want that. this way we'd cleanup 
tun.c/route.c big time
(13:19:00) cron2: first nitpick: "add an IPv4 address to an interface"
(13:19:11) syzzer: ordex: I don't have much to add to the dicussion, but I do 
want to say that both the netlink and the multisocket stuff is very cool!
(13:19:19) cron2: we should be sure that is what we want, "add to whatever is 
already there" instead of "set address for an interface"
(13:19:35) ordex: syzzer: glad to hear that! :)
(13:20:15) ordex: cron2: if we want to "set", the external layer could do a 
"flush all addrs on $dev", "ass new $addr"
(13:20:34) ordex: not sure we have a way to flush right now, we could be 
implemented in the current API
(13:21:04) ordex: cron2: your concerns comes from the actual behaviour of 
"ifconfig" ?
(13:21:11) ordex: because with iproute2 we already do "ip addr add"
(13:21:18) ordex: and this API is basically the same as that
(13:21:50) cron2: it's a bit of "what do we really use?" plus "ifconfig can 
only do <x>" plus "omg, windows"
(13:22:17) cron2: and what we *use* today is "set".  Calling "ip addr add" 
might just work because a new tun/tap has no address, but technically that's 
just coincidence
(13:22:27) ordex: :D
(13:22:30) ordex: nice to know
(13:22:31) dazo: I think supporting "add" instead of just "set" is more future 
proof, even though now we can only support a single VPN IP address per IP stack
(13:22:54) dazo: today
(13:22:58) cron2: but maybe we want *add*, to give people more rope to hang 
themselve :-) (predefined tun interface, with some addresses already there that 
(13:22:59) ordex: yeah what dazo said. but maybe then we should add a 
"flush_addr" API, so that the external logic can make that behaviour clear
(13:23:10) dazo: yeah, that makes sense
(13:23:34) ordex: hmmm
(13:23:44) cron2: so, this is one thing that came to my mind :) - "be clear on 
what we want, set or add, and if we want set, make the API support that"
(13:23:48) cron2: so, next thing
(13:24:41) cron2: if we use that API as an internal upper half / lower half for 
route.c, tun.c, splitting "net_iface_up()" and "net_addr_v4_add()" will cause 
extra exec() calls on some of the ifconfig plattforms
(13:24:59) cron2: right now we do "ifconfig tun0 up" and be done with it
(13:25:04) ordex: yeah, is that a problem?
(13:26:30) cron2: we'd need to test this (if "ifconfig tun0 up" will nicely 
work everywhere) - I assume it's not a hard problem, I just loathe extra exec() 
calls if not needed
(13:26:32) dazo: Or we could also figure out some kernel APIs on those 
platforms as well, and migrate to a similar approach there too - having 
ifconfig as the fallback there
(13:26:57) cron2: dazo: we do not want to find kernel APIs for Solaris, really 
not :-)
(13:27:01) ordex: :D
(13:27:19) ordex: but, yeah, we need to make sure it works. buildbot should 
safely check that, no?
(13:27:19) dazo: fair point! :)  I was more thinking about *BSD ;-)
(13:28:04) dazo: (I really wonder how widely OpenVPN is used on Solaris 
(13:28:21) cron2: I would see "kernel packet link APIs" as a non-goal.  If 
someone really feels like they need this, good, but since part of the reason we 
want this on linux ("100000 routes" and "non-root, capabilities" ) do not 
really seem to exist for those plattforms
(13:28:49) cron2: anyway
(13:29:00) cron2: the API will not work on windows in its current form
(13:29:06) ordex: oh ok, why?
(13:29:37) cron2: because you pass in a "const char * iface" but you miss the 
service pipe handle
(13:29:53) dazo: oh, true
(13:30:07) cron2: (windows passes "give me a route! give me an ifconfig!" via 
pipe to the iservice daemon)
(13:30:40) ordex: hmmm can't the windows API implementation be the one building 
what the iservice needs?
(13:30:53) ***ordex has no clue about how this works at the moment
(13:31:32) dazo: hmmm .... well, it's ugly, but the service pipe could be a 
global variable ... which would only be defined on Windows
(13:31:45) cron2: dazo: no
(13:32:22) ordex: ah
(13:32:28) cron2: I would tend to add an opaque struct pointer to the API calls 
which they can use to store "things they need" in it
(13:32:31) dazo: the alternative is to have some init() setup ... which 
configures a struct used by this API ... for Linux it would mostly be a NOOP
(13:32:35) ordex: this is similar to the env_set problem with iproute
(13:32:41) ordex: we could have an opaque ctx like for ssl
(13:32:47) ordex: yes
(13:32:49) cron2: yes
(13:32:55) ordex: we all said the same thing I believe :D
(13:33:02) dazo: yeah, that's what I mean too
(13:33:07) dazo: ::)
(13:33:23) ordex: that's probably the best, so we hide all the implementation 
specific requirements in the opaque ctx
(13:33:37) ordex: or any required state
(13:33:56) cron2: ... and if it turns out we run into a platform that cannot do 
"ifconfig tun0 up", we can just have the struct remember "tun wants up, but is 
not yet" and the ifconfig calls can then do that
(13:34:16) dazo: yeah
(13:34:42) ordex: yup
(13:34:56) ordex: this way we can re-use the same ifconfig-implementation for 
the "broken" platforms
(13:34:58) ordex: sounds good :)
(13:35:13) ordex: I think this is already enough for no
(13:35:14) ordex: w
(13:35:24) ordex: I can restructure the API to include the ctx
(13:35:35) dazo: sounds good to me
(13:35:50) cron2: the net_route_* functions *should* work, though we use an 
interface index on windows, not the name
(13:36:18) cron2: (and since it's not always the same interface, using "init()" 
for this won't work)
(13:36:19) ordex: can't thatbe retrieved from the implementation? also netlink 
retrieves the ifindex from the name
(13:36:30) cron2: we might not have a name
(13:36:35) ordex: ah
(13:36:47) cron2: like, for the "where is the current ipv6 default gateway?  so 
we can add a $host/128 bypass route"
(13:37:06) cron2: I think the "where is the route?" API will spit out an 
(13:37:15) ordex: hmm will check that
(13:37:36) dazo: hmmm ... is that index something we could put into a ctx 
instead of providing an interface name each time?
(13:37:54) ordex: it's a bit ugly...but we could have some openvpn_iface_type_t
(13:38:03) ordex: that gets redefined based on the implementation we choose
(13:38:11) ordex: char * for those using a name
(13:38:16) ordex: or $whatever for windows
(13:38:17) cron2: dazo: "all but one" route will point to the tun/tap 
interface, and *one* (redirect-gateway) will point elsewhere, which might only 
be identified by an index...
(13:38:23) cron2: yeah
(13:38:49) cron2: making "const char *iface" an "openvpn_platform_if_t iface" 
might make this work
(13:39:02) ordex: yeah some name like that
(13:39:03) dazo: I was thinking an "init ctx" call could do the ifindex lookup 
and save the needed details needed for each platform
(13:39:44) dazo: if it saves ifindex + a char *, or what it uses later on would 
be up to the "sitnl" implementation for each platform
(13:39:48) ordex: this means we might need to call the init() everytime we have 
to work on a different ifname
(13:39:55) cron2: dazo: we have no name
(13:40:05) ordex: that too :P
(13:40:23) ordex: so basically we have no "common type" that we can use in our 
(13:40:26) cron2: (even for the tap interface on windows, we take great care to 
use the ifindex today :))
(13:40:33) dazo: I was thinking of the "char *iface"
(13:40:34) ordex: we need to redefine the type per implementation..
(13:40:42) dazo: so bad terminology from my side :)
(13:41:14) cron2: ordex: I think most plattforms will be fine with char * 
iface, as long as we find a way to transport an integer without too much hurt
(13:41:46) dazo: Then openvpn_platform_if_t iface would be a bit cleaner
(13:41:50) ordex: yap
(13:41:54) cron2: yep
(13:42:06) cron2: I was thinking about struct/union, but that just complicates 
things for everybody
(13:42:23) mattock: I will have to get some lunch now
(13:42:41) mattock: but do not let that stop you from continuing :P
(13:42:44) dazo: mattock: bring your laptop and Internet connection! :-P
(13:42:48) ordex: cron2: well, but where do we use it? if it's for a single 
member, better to just redefine the type
(13:42:57) ordex: :D
(13:43:13) ordex: anyway, let's try the openvpn_platform_if_t approach
(13:43:17) cron2: ordex: this *should* have conveyed "... so I do not think 
struct/union is a good idea" :)
(13:43:18) ordex: anyway I can test this on windows?
(13:43:28) ordex: ah :D
(13:43:30) ordex: ok
(13:44:28) cron2: ordex: if you have _init(), you could just experiment with 
one of the easy ones (net_route_v6_add())...
(13:44:37) ordex: ok
(13:44:52) ordex: and btw, converting windows is not part of this patchset yet
(13:45:10) ordex: so ensuring it works might come later, even though the API 
should be good enough to not being touched anymore
(13:45:37) cron2: ordex: understood :) - and that's why it was important you 
urged us to review the API today
(13:45:43) cron2: (thanks)
(13:45:44) ordex: yup :)
(13:46:08) ordex: it would be nice if we could rediscuss this next week 
(hopefully with these changes applied by me)
(13:46:15) ordex: but for now i think we are good
(13:46:16) ordex: !
(13:47:40) ordex: anything else we want to mention?
(13:48:04) ***cron2 is a bit exhausted
(13:48:14) ordex: food for everybody then ;P
(13:48:37) syzzer: yeah, food! :D
(13:48:39) cron2: mattock: any news on driver signing?  Or have you avoided 
even thinking about that?
(13:48:39) syzzer: :p
(13:49:08) cron2: syzzer: you haven't said *that* much :)
(13:50:42) syzzer: cron2: correct, but I still need food ;-)
(13:50:54) cron2: hrhrh :)
(13:51:11) cron2: syzzer: so how's your busy-level these days?  Haven't seen 
much from you lately
(13:51:21) syzzer: cron2: slowly decreasing :)
(13:51:26) cron2: promising
(13:51:39) dazo: down to 128% ... or something around there? :-P
(13:52:03) syzzer: new team member starting today, so still need to invest time 
to get everything rolling.
(13:52:26) syzzer: hopefully once the new team members are up-and-running, I 
get time to do other stuff again
(13:52:29) cron2: dazo: only 128%?  Are you neglecting your family, or not 
sleeping enough? ;)
(13:53:12) dazo: sleeping is overrated
(13:53:24) dazo: ;-)
(14:22:40) mattock: cron2: no progress on the driver signing front - national 
holidays and all that got in the way
(14:22:59) mattock: I will start the via dolorosa soon enough, though
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to