Re: [Openvpn-devel] [PATCH v2 1/7] implement platform generic networking API

Hi, On 26/11/2018 22:55, Arne Schwabe wrote: > Am 11.10.18 um 20:41 schrieb Antonio Quartulli: >> tun.c and route.c contain all the code used by openvpn >> to manage the tun interface and the routing table on all >> the supported platforms. >> >> Across the years, this resulted in a longer functions >> and series of ifdefs. >> >> This patch introduces a new "networking API" which aims at >> creating a simple abstraction between the tun/route logic >> and the platform dependent code. >> >> The is API expected to be implemented outside of tun.c/route.c >> by using platform specific functionalities. > > If I understand it right, the goal is to create a platform independent > API, Android needs either still hacks in the non platform specific code > or the API needs to communicate also > > - route/adding addr before interface up > - type of route to add (android wants to ignores the host route to VPN > server and wants to isntall a 0.0.0.0/0 instead of two /1 even with def1 > in place, the last one to workaround buggy Samsung code that special > cases 0.0.0.0/0 but sadly still needed. > > Should we try to design the API right from the start to allow also for > these specifics? > This sounds like a problem that has to be addressed at a layer above compared to what this networking API is doing. With this I mean that the specific "Android case" you explained cannot be addressed by changing the networking API (meant to be low level API to configure/deconfigure th enetworking stack), but should be taken care by the login in tun.c/route.c directly. What yo are suggesting is a change to the logic passing the information from the control plane to the platform dependent code. This change to me seems independent from the technology used to configure the interface (i.e. iproute/nettools/netlink/anything-else). What you are after is probably an abstraction similar to the one we have in OpenVPN 3, but that one is indeed implemented at an higher level compared to what we are introducing with this patchset. If you note, this is why my patches for OpenVPN 3 consists of two components. In my opinion, the logic change you are talking about is not required because: - this is already implemented in tun.c/route.c at the moment and won't be changed for now - this can be "improved" later once this networking API is in place, because the code will have to deal with will already be much slimmer. Attempting to work on both layers with one big change will just make things more complicated imho, hence my proposal to go step by step. Best Regards, -- Antonio Quartulli