There's clearly some problem, others have seen breakage too, but I don't
see why replacing -netmask to /prefix would change anything..
On 13 September 2016 22:35:54 Sander van Kranenburg <san...@vkranenburg.nl>
wrote:
Hi,
GMBL so it's probably my vpn provider that doesn't work with 6.0.
Thx for your time and the great support.
Best regards,
Sander van Kranenburg
-----Oorspronkelijk bericht-----
Van: Stuart Henderson [mailto:s...@spacehopper.org]
Verzonden: dinsdag 13 september 2016 23:26
Aan: Sander van Kranenburg <san...@vkranenburg.nl>
CC: ports@openbsd.org
Onderwerp: Re: openvpn broken caused by a change in route add and delete
On 2016/09/13 21:20, Sander van Kranenburg wrote:
Hi,
Are you at openbsd 6.0 at the moment?
This is my uname -a OpenBSD openbsd.HOME.local 6.0 GENERIC#0 i386.
-netmask doesn't work at all for me since i updated tot 6.0
-current from a few days ago, but I just also tested it on 6.0 release.
Van: Stuart Henderson [mailto:s...@spacehopper.org]
Verzonden: dinsdag 13 september 2016 23:07
Aan: Sander van Kranenburg <san...@vkranenburg.nl>
CC: ports@openbsd.org
Onderwerp: Re: openvpn broken caused by a change in route add and
delete
On 2016/09/13 19:29, Sander van Kranenburg wrote:
> Hi,
>
> As far as i know -netmask doesn't work anymore.
> We need to add the netbits tot the network adres like openvpn is doing
with ipv6.
-netmask is expected to work exactly the same as specifying ip/prefix, and
it does work fine here:
# route add -net 192.0.2.0 82.68.199.133 -netmask 255.255.255.0 add net
192.0.2.0: gateway 82.68.199.133 # netstat -rnfinet | grep ^192
192.0.2/24 82.68.199.133 UGS 0 0 - 8 vlan2
# route delete -net 192.0.2.0 -netmask 255.255.255.0 delete net
192.0.2.0 # netstat -rnfinet | grep ^192 #
Exactly the same behaviour as the prefix:
# route add 192.0.2.0/24 82.68.199.133 add net 192.0.2.0/24: gateway
82.68.199.133 # netstat -rnfinet | grep ^192
192.0.2/24 82.68.199.133 UGS 0 0 - 8 vlan2
# route delete 192.0.2.0/24
delete net 192.0.2.0/24
# netstat -rnfinet | grep ^192
#
I think the problem you ran into was something to do with the gateway
address, handling of this *was* changed relatively recently, and not the
syntax of address format to route(8).