Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am Thu, 26 Mar 2020 09:38:49 +0100 schrieb Arne Schwabe : > > RPI? You mean Raspberry PI? > > Maybe on this machine the problem is not a problem. We also use > > OpenVPN 2.4.7 on a ARMv7, and there is no obvious problem, just on > > the old ARMv4. > > > > Finding all problematic places in the code will still be difficult. > > I just look at my RPI and it seems that it has the option you > mentioned set by default: > > cat /proc/cpu/alignment > User: 0 > System: 0 ( (null)) > Skipped: 0 > Half: 0 > Word: 0 > DWord:0 > Multi:0 > User faults: 2 (fixup) Yes, this seems to be the default setting for all newer ARM machines. > But it seems that the CPU will not trap but instead allows unaligned > memory access. > > But since your machine requires that and setting it to 3 (warn+fixup) > actually fixes the problem you should get warning messages in your > dmesg output about the points in the code that trigger this problem. Yes, we decided to solve the problem by setting it to 2. I will have to make a performance test. I expect a lower performance. Additionally this old machine is already slow as hell. Debugging and fixing all eventual alignment problems will most probably take to quite time, which we have no longer for the next release. > And you could then either lookup with gdb what the IP addresse are > pointing to in the the code or (probably easier) configure the kernel > to send a SIGBUS, so you get a core image and can print a backtrace. > If we know what code path actually trigger the unaligned access we > can take a look and figure out what is wrong. Gert has done similar > things with the sparc machines in the past. Yes again. Finding all occurences will need a few different setups. By the way: Stupid as I am it didn't occor to me to check the setting of /proc/cpu/alignment on the ARMv7 machine, where the problems do not occur. Now I did and surprise, surprise: It's already set to 2 there :-)) -- Servus Michael ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am 25.03.20 um 19:35 schrieb Michael Kress: > Hello Arne, > > Am Wed, 25 Mar 2020 12:50:34 +0100 > schrieb Arne Schwabe : >>> 1) Do you run automated tests of the OpenVPN code on any build >>> server? >>> >>> 2) If that is the case, is there any test with a version, where >>>-DVERIFY_ALIGNMENT is enabled? >>> >> >> I never heard of this option and Google does not want to spit >> something out for me for that. > > That's a #define in the OpenVPN code, for example in > src/openvpn/buffer.h line 943 ;-) Ah those. Yeah. They are mainly for performance reasons and debugging I think. If I also remember correctly buffer.h is written in a way that these *not* actually trigger unaligned access on a CPU level. But for performance reason having the uint8_t array aligned to 4bytes will make everything faster. > RPI? You mean Raspberry PI? > Maybe on this machine the problem is not a problem. We also use OpenVPN > 2.4.7 on a ARMv7, and there is no obvious problem, just on the old > ARMv4. > > Finding all problematic places in the code will still be difficult. I just look at my RPI and it seems that it has the option you mentioned set by default: cat /proc/cpu/alignment User: 0 System: 0 ( (null)) Skipped:0 Half: 0 Word: 0 DWord: 0 Multi: 0 User faults:2 (fixup) But it seems that the CPU will not trap but instead allows unaligned memory access. But since your machine requires that and setting it to 3 (warn+fixup) actually fixes the problem you should get warning messages in your dmesg output about the points in the code that trigger this problem. And you could then either lookup with gdb what the IP addresse are pointing to in the the code or (probably easier) configure the kernel to send a SIGBUS, so you get a core image and can print a backtrace. If we know what code path actually trigger the unaligned access we can take a look and figure out what is wrong. Gert has done similar things with the sparc machines in the past. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Hello Arne,
Am Wed, 25 Mar 2020 12:50:34 +0100
schrieb Arne Schwabe :
> > 1) Do you run automated tests of the OpenVPN code on any build
> > server?
> >
> > 2) If that is the case, is there any test with a version, where
> >-DVERIFY_ALIGNMENT is enabled?
> >
>
> I never heard of this option and Google does not want to spit
> something out for me for that.
That's a #define in the OpenVPN code, for example in
src/openvpn/buffer.h line 943 ;-)
> Compression adds a one byte header in the packet making it all
> unaligned. The newer lz4 with swap, or v2 compression methods try to
> avoid this misaligned, mainly for speed on platforms where unaligned
> access comes with a penality.
Yes, so I think, that the size of the payload of the sent ICMP-Pings
over the Tunnel changes, if the LZO compression kicks in for this
packet or not.
> I think there might still be unaligned access that are in the code
> but I am not sure how to debug them. Is there an easy way to
> reproduce them? Can a RPI configured to throw those warnings?
Yes, just compile OpenVPN with the additional
CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
Then increase verbositiy of the logs to 14 and grep the log for "ERROR"
Of course you have to enable --comp-lzo
RPI? You mean Raspberry PI?
Maybe on this machine the problem is not a problem. We also use OpenVPN
2.4.7 on a ARMv7, and there is no obvious problem, just on the old
ARMv4.
Finding all problematic places in the code will still be difficult.
--
Servus
Michael
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
>> LZO is known to miscompile with gcc 10 and requires >> -fno-strict-aliasing to compile. and also in my OpenVPN for Android >> app I have to compile lzo with -O1 instead -O2 since it otherwise >> segfaults on armv7a. Android uses LLVM/clang to compile so the broken >> behaviour is present also on other compilers. I never investigated >> which optimisation flag does break in clang/llvm/armv7a. > > The alignment errors happen in OpenVPN code, not in LZO code. > We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from > 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked > statically to the old compiled lib. I doubt that the compiler itself > changes anything here. > >> But bottom line is that you probably are running in a similar and I >> would advise to compile lzo with less optimisation. > > Thanks for the suggestion! > > Anyways I recompiled LZO without any optimazations and then OpenVPN > 2.4.8. Unfortunatelly this changed nothing. > > A few questions: > > 1) Do you run automated tests of the OpenVPN code on any build server? > > 2) If that is the case, is there any test with a version, where >-DVERIFY_ALIGNMENT is enabled? > I never heard of this option and Google does not want to spit something out for me for that. > 3) If that is also the case, can you see any ERRORS regarding the >alignment in the logs? > > The problem is, that we do not have any power over the clients. It > might well be, that there are even OpenVPN 2.2 clients out there. > Compression adds a one byte header in the packet making it all unaligned. The newer lz4 with swap, or v2 compression methods try to avoid this misaligned, mainly for speed on platforms where unaligned access comes with a penality. I think there might still be unaligned access that are in the code but I am not sure how to debug them. Is there an easy way to reproduce them? Can a RPI configured to throw those warnings? ARne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
вт, 24 мар. 2020 г. в 22:19, Michael Kress : > Am Tue, 24 Mar 2020 11:21:56 +0100 > schrieb Arne Schwabe : > > > Am 23.03.20 um 17:11 schrieb Michael Kress: > > > Hello list, > > > > > > There seems to be some kind of alignment problem in OpenVPN 2.4 > > > versions on ARMv4 based machines (32 bit), especially when lzo > > > compression kicks in. > > > > LZO is known to miscompile with gcc 10 and requires > > -fno-strict-aliasing to compile. and also in my OpenVPN for Android > > app I have to compile lzo with -O1 instead -O2 since it otherwise > > segfaults on armv7a. Android uses LLVM/clang to compile so the broken > > behaviour is present also on other compilers. I never investigated > > which optimisation flag does break in clang/llvm/armv7a. > > The alignment errors happen in OpenVPN code, not in LZO code. > We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from > 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked > statically to the old compiled lib. I doubt that the compiler itself > changes anything here. > > > But bottom line is that you probably are running in a similar and I > > would advise to compile lzo with less optimisation. > > Thanks for the suggestion! > > Anyways I recompiled LZO without any optimazations and then OpenVPN > 2.4.8. Unfortunatelly this changed nothing. > > A few questions: > > 1) Do you run automated tests of the OpenVPN code on any build server? > > 2) If that is the case, is there any test with a version, where >-DVERIFY_ALIGNMENT is enabled? > there are several test suites that you can run using "make check" (it performs several e2e tests and cmocka testing). also, there's openvpn vagrant suite intended for running several VMs on VirtualBox (and build and test openvpn on them) also, there's buildbot (not exposed to internet, but build logs available on mailing list) and there's travis-ci for express tests (actually "make check") for several build configurations: https://travis-ci.org/github/OpenVPN/openvpn I think we can add -DVERIFY_ALIGNMENT to some travis-ci builds > > 3) If that is also the case, can you see any ERRORS regarding the >alignment in the logs? > > The problem is, that we do not have any power over the clients. It > might well be, that there are even OpenVPN 2.2 clients out there. > > -- > Servus > Michael > > > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am Tue, 24 Mar 2020 11:21:56 +0100 schrieb Arne Schwabe : > Am 23.03.20 um 17:11 schrieb Michael Kress: > > Hello list, > > > > There seems to be some kind of alignment problem in OpenVPN 2.4 > > versions on ARMv4 based machines (32 bit), especially when lzo > > compression kicks in. > > LZO is known to miscompile with gcc 10 and requires > -fno-strict-aliasing to compile. and also in my OpenVPN for Android > app I have to compile lzo with -O1 instead -O2 since it otherwise > segfaults on armv7a. Android uses LLVM/clang to compile so the broken > behaviour is present also on other compilers. I never investigated > which optimisation flag does break in clang/llvm/armv7a. The alignment errors happen in OpenVPN code, not in LZO code. We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked statically to the old compiled lib. I doubt that the compiler itself changes anything here. > But bottom line is that you probably are running in a similar and I > would advise to compile lzo with less optimisation. Thanks for the suggestion! Anyways I recompiled LZO without any optimazations and then OpenVPN 2.4.8. Unfortunatelly this changed nothing. A few questions: 1) Do you run automated tests of the OpenVPN code on any build server? 2) If that is the case, is there any test with a version, where -DVERIFY_ALIGNMENT is enabled? 3) If that is also the case, can you see any ERRORS regarding the alignment in the logs? The problem is, that we do not have any power over the clients. It might well be, that there are even OpenVPN 2.2 clients out there. -- Servus Michael ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am 23.03.20 um 18:19 schrieb Michael Kress: > Hi, > > Unfortunatelly it seems, we are stuck to LZO for now, because it has > been configured in the clients, which run 2.3. Most of these clients are > offline most of the time, so reconfiguring or upgrading all of them > before updating the server will become difficult. > > You are completely right: One reason for upgrading to OpenVPN 2.4 is > indeed this feature. Another reason is, that Client and Server can > negotiate to use AES instead of Blowfish :-) > You can use client-connect to disable compression for newer clients. Example here: http://plai.de/android/peerid.py I would suggest stub-v2 instead lz4 however since that effectively disables compression completely (voracle). AS also takes this approach. Maybe we should make that default in newer versions. Arne P.S.: Sorry double copy, forgot to add CC to list in first email. signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Am 23.03.20 um 17:11 schrieb Michael Kress: > Hello list, > > There seems to be some kind of alignment problem in OpenVPN 2.4 > versions on ARMv4 based machines (32 bit), especially when lzo > compression kicks in. LZO is known to miscompile with gcc 10 and requires -fno-strict-aliasing to compile. and also in my OpenVPN for Android app I have to compile lzo with -O1 instead -O2 since it otherwise segfaults on armv7a. Android uses LLVM/clang to compile so the broken behaviour is present also on other compilers. I never investigated which optimisation flag does break in clang/llvm/armv7a. But bottom line is that you probably are running in a similar and I would advise to compile lzo with less optimisation. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
Hi,
Unfortunatelly it seems, we are stuck to LZO for now, because it has
been configured in the clients, which run 2.3. Most of these clients are
offline most of the time, so reconfiguring or upgrading all of them
before updating the server will become difficult.
You are completely right: One reason for upgrading to OpenVPN 2.4 is
indeed this feature. Another reason is, that Client and Server can
negotiate to use AES instead of Blowfish :-)
Servus
Michael
(Sorry, should have answered to the list in the first place)
Am Mon, 23 Mar 2020 22:00:12 +0500
schrieb Илья Шипицин :
> thank you for wonderful investigation.
>
>
> however, are there reasons for using lzo ? it consumes too much cpu
> (comparing to lz4). also, it highly depends on traffic itself, many
> application already compress their bytes themselves.
>
> if you are stick to lzo, because it is propagated to all configs, in
> 2.4 you can push compression options just like dhcp option from
> server to clients (and it wins over the config file).
>
> пн, 23 мар. 2020 г. в 21:29, Michael Kress :
>
> > Hello list,
> >
> > There seems to be some kind of alignment problem in OpenVPN 2.4
> > versions on ARMv4 based machines (32 bit), especially when lzo
> > compression kicks in.
> >
> > History:
> >
> > We run OpenVPN 2.3 happily on a ARMv4 machine. Now we want to
> > upgrade to 2.4 because of automatically negotiated AES instead of
> > BlowFish. The configuration is unchanged, only OpenVPN and OpenSSL
> > get upgraded. The tunnel gets up, but some traffic is dropped on
> > the OpenVPN server side MULTI: bad source address from client
> > [10.1.0.75], packet dropped
> >
> >
> > Short version of the story:
> > ---
> > Only this helps:
> > $ echo 3 > /proc/cpu/alignment
> > Compiling with CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> > leads to a lot of alignment failure messages
> >
> > Long version of the story:
> > --
> > - Authentication via certificates
> > - both server and client are ARMv4 based machines
> > - Tunnel IP net is 10.1.0.0/24
> > - LZO compression with --comp-lzo (adaptive)
> > - IP of OpenVPN server: 192.168.202.82/22
> > IP of OVPN_Client1: 192.168.201.116/22
> > IP of OVPN_Client2: 192.168.203.84/22
> >
> > A ping from the OpenVPN client to the OpenVPN server works,
> > as long the packet payload has a certain size
> > $ ping 10.1.0.1 -s 350
> >
> > The same ping situation but with a default payload ping failes:
> > $ ping 10.1.0.1
> > The server complains with
> > Mon Mar 23 14:54:06 2020 us=663594 OVPN_Client1/192.168.201.116
> > MULTI: bad source address from client [10.1.0.75], packet dropped
> >
> > Interesting: The source IP address is different with every ping
> > packet reaching the OpenVPN server: 10.1.0.XXX, with XXX is a
> > random number from 0 to 254. Eventually a ping becomes answered
> > with a pong, when luckily the correct tunnel IP address is used
> > (chance is 1 to 255 :-)
> >
> > With the bigger ping payload _every_ packet gets answered, because a
> > manually entered debug line prints the correct source address of the
> > packet.
> >
> > Removing LZO compression also solves the problem: With --comp-lzo
> > removed from the client and server, no packets are dropped. We used
> > LZO 2.06 and 2.10, they behave the same.
> >
> > Modifying the cipher and/or the hash algorithm doesn't change
> > anything, even if no encryption is used at all (none)
> >
> >
> > Then I compilied OpenVPN (all of the three versions) with
> >CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> > and started OpenVPN very verbose (verb 14).
> >
> > This is tail -f /var/log/openvpn.log | grep ERROR:
> > Mon Mar 23 13:25:59 2020 us=74 OVPN_Client2/192.168.202.84:53155
> > ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562
> > I=/1077682176 Mon Mar 23 13:26:00 2020 us=66
> > OVPN_Client2/192.168.202.84:53155 ERROR: Alignment at mroute.h/196
> > ptr=0x00bfec30 OLC=461/84/2562 I=crypto.c/397
> > Mon Mar 23 13:26:00 2020 us=69
> > OVPN_Client1/192.168.201.116:49610 ERROR: Alignment at proto.c/48
> > ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176 Mon Mar 23 13:26:00
> > 2020 us=69 OVPN_Client1/192.168.201.116:49610 ERROR: Alignment
> > at mss.c/56 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176 Mon Mar 23
> > 13:26:00 2020 us=72 OVPN_Client1/192.168.201.116:49610 ERROR:
> > Alignment at mroute.h/196 ptr=0x00bfec30 OLC=537/84/2562
> > I=crypto.c/573 Mon Mar 23 13:26:00 2020 us=75
> > OVPN_Client2/192.168.202.84:53155 ERROR: Alignment at proto.c/48
> > ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176 Mon Mar 23 13:26:00
> > 2020 us=75 OVPN_Client2/192.168.202.84:53155 ERROR: Alignment
> > at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176 Mon Mar 23
> > 13:26:01 2020 us=71 OVPN_Client2/192.168.202.84:53155 ERROR:
> > Alignment at mroute.h/196 ptr=0x00bfec30 OLC=461/84/2562
> > I=crypto.c/397 Mon Mar 23 13:26:01 2020 us=73
> >
Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?
thank you for wonderful investigation.
however, are there reasons for using lzo ? it consumes too much cpu
(comparing to lz4). also, it highly depends on traffic itself, many
application already compress their bytes themselves.
if you are stick to lzo, because it is propagated to all configs, in 2.4
you can push compression options just like dhcp option from server to
clients (and it wins over the config file).
пн, 23 мар. 2020 г. в 21:29, Michael Kress :
> Hello list,
>
> There seems to be some kind of alignment problem in OpenVPN 2.4
> versions on ARMv4 based machines (32 bit), especially when lzo
> compression kicks in.
>
> History:
>
> We run OpenVPN 2.3 happily on a ARMv4 machine. Now we want to upgrade
> to 2.4 because of automatically negotiated AES instead of BlowFish. The
> configuration is unchanged, only OpenVPN and OpenSSL get upgraded. The
> tunnel gets up, but some traffic is dropped on the OpenVPN server side
> MULTI: bad source address from client [10.1.0.75], packet dropped
>
>
> Short version of the story:
> ---
> Only this helps:
> $ echo 3 > /proc/cpu/alignment
> Compiling with CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> leads to a lot of alignment failure messages
>
> Long version of the story:
> --
> - Authentication via certificates
> - both server and client are ARMv4 based machines
> - Tunnel IP net is 10.1.0.0/24
> - LZO compression with --comp-lzo (adaptive)
> - IP of OpenVPN server: 192.168.202.82/22
> IP of OVPN_Client1: 192.168.201.116/22
> IP of OVPN_Client2: 192.168.203.84/22
>
> A ping from the OpenVPN client to the OpenVPN server works,
> as long the packet payload has a certain size
> $ ping 10.1.0.1 -s 350
>
> The same ping situation but with a default payload ping failes:
> $ ping 10.1.0.1
> The server complains with
> Mon Mar 23 14:54:06 2020 us=663594 OVPN_Client1/192.168.201.116 MULTI:
> bad source address from client [10.1.0.75], packet dropped
>
> Interesting: The source IP address is different with every ping packet
> reaching the OpenVPN server: 10.1.0.XXX, with XXX is a random number
> from 0 to 254. Eventually a ping becomes answered with a pong, when
> luckily the correct tunnel IP address is used (chance is 1 to 255 :-)
>
> With the bigger ping payload _every_ packet gets answered, because a
> manually entered debug line prints the correct source address of the
> packet.
>
> Removing LZO compression also solves the problem: With --comp-lzo removed
> from the client and server, no packets are dropped. We used LZO 2.06 and
> 2.10, they behave the same.
>
> Modifying the cipher and/or the hash algorithm doesn't change anything,
> even if no encryption is used at all (none)
>
>
> Then I compilied OpenVPN (all of the three versions) with
>CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> and started OpenVPN very verbose (verb 14).
>
> This is tail -f /var/log/openvpn.log | grep ERROR:
> Mon Mar 23 13:25:59 2020 us=74 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=66 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=461/84/2562
> I=crypto.c/397
> Mon Mar 23 13:26:00 2020 us=69 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=69 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=72 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=537/84/2562
> I=crypto.c/573
> Mon Mar 23 13:26:00 2020 us=75 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=75 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=71 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=461/84/2562
> I=crypto.c/397
> Mon Mar 23 13:26:01 2020 us=73 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=73 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=77 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=537/84/2562
> I=crypto.c/573
> Mon Mar 23 13:26:01 2020 us=80 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at proto.c/48 ptr=0x00c43188 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=80 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c43188 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:02 2020 us=68 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at
