Using send() on UDP socket -- is it intended?

[SkyArbor]

Hi, I noticed speederv2_wepoll.exe using send() when sending packet to remote server, and using sendto() when sending packet to local OpenVPN server, and I'm wondering the reason behind it.

（calling sendto()）

（calling `send()`）

Calling send() introduces a special behaviour on my Windows OS. After OpenVPN changes the route table, the socket itself ignores the change and uses original route. Say, I used client side config in this guide without additional changes to my route table, and my OpenVPN server pushed redirect-gateway def1 option to client. It still worked perfectly.

A simple script can be used to reproduce this behaviour:

import os
import socket
from time import sleep

if __name__ == "__main__":
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    s.connect(('8.8.8.8', 10086))
    while True:
        s.send(b'abcd')
        sleep(1)

Run the script and then connect OpenVPN, OpenVPN won't be able to catch its traffic. Packets still fly to 8.8.8.8, and bypasses the OpenVPN server.

In a word, Using send() strangely avoids OpenVPN hijacking UDPspeeder 's traffic. Is it the reason of using send()? Whether or not, I suggest adding comment to source code. I can't find documentation about this behaviour. It may be changed in the future.

[wangyu-]

In a word, Using send() strangely avoids OpenVPN hijacking UDPspeeder 's traffic. Is it the reason of using send()?

No that's not the reason.   I suggest always adding routing exceptions to avoid openvpn hijacking UDPspeeder's traffic, instead of relying on this behavior.

The reason I use send (or connected socket) for some codes is to make the programming a bit easier for me.

Some other codes are forced to use sendto, since that's needed for communicate with multiple remote points.

Theoretically I can always use sendto.