Alignment Problem on ARM

[lordrasmus]

if the address in addr_ptr is not aligned correctly, the wrong bytes are written on arm replacing * operator with memcpy fixes the issue

Thank you for your contribution

You are welcome to open PR, but they are used for discussion only. All patches must eventually go to the openvpn-devel mailing list for review:

• https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Please send your patch using git-send-email. For example to send your latest commit to the list:

$ git send-email [email protected] HEAD~1

For details, see these Wiki articles:

• https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation
• https://community.openvpn.net/openvpn/wiki/Contributing

[schwabe]

Hm, the pointers point to uint32 in non-packed struct as far as I can see. How should the alignment get screwed here?

[lordrasmus]

i didn't checked why the alignment is screwed

i'm using openvpn as a client with client-nat on an arm platform openvpn 2.3.11 was working fine, the problem started after upgrading to 2.4.0

i'm in holiday this week but i remember what happened i can investigate further why it happens when i'm back in my company

a ping with tcpdump and 2.3.11 looks like this

IP 1.2.3.4 > 5.6.7.8: ICMP echo request was correctly translated to this IP 1.2.3.4 > 192.168.100.5: ICMP echo request

after upgrade to 2.4.0 it was translated to this IP 1.2.3.192 > 168.100.5.8: ICMP echo request

i loaded openvpn in gdb and checked the address of addr_ptr in client_nat_transform the address was something like 0x...5

so maybe the fix has to be made somewhere else i guess between 2.3.11 and 2.4.0 the alignment of the parameter ipbuf was changed

if it helps i can have a look at the generated assembler code and check how the address in addr_ptr ist used but i guess i will find a instruction which needs a 4 or 8 byte alignment

[TinCanTech]

The syntax of --client-nat has changed , possibly this is related. Where alias had two parameters before, it now only supports one.

[lordrasmus]

the config is pushed from the server like this

PUSH: Received control message: 'PUSH_REPLY,route 172.16.0.1,topology net30,ping 50,ping-restart 110,client-nat snat 10.100.101.0 255.255.255.0 10.10.0.0,route 172.16.0.0 255.255.192.0,ifconfig 172.16.0.50 172.16.0.49'

[ordex]

anybody knows if this is still a problem? Many people run openvpn on arm (including myself) and unaligned access was never reported. (But not sure who uses client-nat)

[cron2]

Hi,

On Sat, Sep 17, 2022 at 06:02:52AM -0700, Antonio Quartulli wrote:

anybody knows if this is still a problem? Many people run openvpn on arm (including myself) and unaligned access was never reported. (But not sure who uses client-nat)

I think ARM has no general problem with unaligned access, this smells more like structure padding / rounding errors in the client-nat code.

But, someone would need to actually test openvpn with client-nat on ARM (old and new...) to see if this problem still persists. Volunteers? ;-)

gert

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***