internal DHCP ip clash only on Dusseldorf UDP

[DudeOfLondon]

Code: Select all

Sat Jun 29 16:19:04 2019 us=380442 Set TAP-Windows TUN subnet mode network/local/netmask = 10.66.4.0/10.66.4.254/255.255.255.0 [SUCCEEDED]
Sat Jun 29 16:19:04 2019 us=380442 MANAGEMENT: Client disconnected
Sat Jun 29 16:19:04 2019 us=380442 ERROR: There is a clash between the --ifconfig local address and the internal DHCP server address -- both are set to 10.66.4.254 -- please use the --ip-win32 dynamic option to choose a different free address from the --ifconfig subnet for the internal DHCP server
Sat Jun 29 16:19:04 2019 us=380442 Exiting due to fatal error

Hi I get the above error when connecting to the ECC-UDP_Dusseldorf server via OpenVPN program on Windows.
The Frankfurt server, for instance, works fine though.
How to fix that?

[parityboy]

@OP

Interesting...do you not use the usual 192.168.x.x. addressing scheme on your LAN, or is this on a mobile Windows device?

[DudeOfLondon]

It's on a windows desktop PC. And I use the 192.168.2.x scheme that is provided by the router.
Meanwhile, the error isn't occurring anymore, maybe it was server-side or something else, that got mixed up.

[df]

Looks like there is a bug in our random IP generating code that could cause you to get assigned the internal DHCP IP as your internal client IP.
The bash code that generates the last octet for the internal IP in the server-side OpenVPN --up script is:
echo $[ 3 + $[ RANDOM % 254 ]]
The bash man page says $RANDOM is "a random integer between 0 and 32767".
That means the lowest octet is 3 (which is what we wanted), but the highest is .256, which would be invalid since that can only go up to .255.
Since we don't even want it to get to .254, I'll change the code to:
echo $[ 3 + $[ RANDOM % 251 ]]
which would still make the lowest possible octet 3, but the highest possible is now .253