Re: [Openvpn-devel] OpenVPN 2.4.8 released
> It would be interesting too what error message there is in setupapi.dev.log:
>
I found a win7 vm with openvpn 2.4.6. try to upgrade to 2.4.8 and get
the same result.
setupapi.dev.log attached. there are some international characters but
I think they are not important.
I snapshot the vm before upgrade. so I can repeat the procedure if necessary.
Regards,
tbskyd
[Boot Session: 2019/11/07 11:24:16.500]
>>> [Device Install (UpdateDriverForPlugAndPlayDevices) - tap0901]
>>> Section start 2019/11/07 11:26:35.994
cmd: "C:\Program Files\TAP-Windows\bin\tapinstall.exe" update "C:\Program
Files\TAP-Windows\driver\OemVista.inf" tap0901
dvi: Set selected driver complete.
dvi: {Build Driver List} 11:26:36.119
dvi: Searching for hardware ID(s):
dvi: tap0901
cpy: Policy is set to make all digital signatures equal.
dvi: Processing a single INF: 'c:\program
files\tap-windows\driver\oemvista.inf'
inf: Opened INF: 'c:\program files\tap-windows\driver\oemvista.inf'
([strings])
sig: {_VERIFY_FILE_SIGNATURE} 11:26:36.135
sig: Key = oemvista.inf
sig: FilePath = c:\program files\tap-windows\driver\oemvista.inf
sig: Catalog = c:\program files\tap-windows\driver\tap0901.cat
!sig: Verifying file against specific (valid) catalog failed!
(0x800b0109)
!sig: Error 0x800b0109: A certificate chain processed, but
terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 11:26:36.369
sig: {_VERIFY_FILE_SIGNATURE} 11:26:36.369
sig: Key = oemvista.inf
sig: FilePath = c:\program files\tap-windows\driver\oemvista.inf
sig: Catalog = c:\program files\tap-windows\driver\tap0901.cat
sig: Success: File is signed in Authenticode(tm) catalog.
sig: Error 0xe242: The publisher of an Authenticode(tm)
signed catalog has not yet been established as trusted.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe242)} 11:26:36.447
dvi: Created Driver Node:
dvi: HardwareID - tap0901
dvi: InfName - c:\program
files\tap-windows\driver\oemvista.inf
dvi: DevDesc - TAP-Windows Adapter V9
dvi: DrvDesc - TAP-Windows Adapter V9
dvi: Provider - TAP-Windows Provider V9
dvi: Mfg - TAP-Windows Provider V9
dvi: ModelsSec- tap0901.NTamd64
dvi: InstallSec - tap0901.ndi
dvi: ActualSec- tap0901.ndi
dvi: Rank - 0x00ff
dvi: Signer - OpenVPN Inc.
dvi: Signer Score - Authenticode
dvi: DrvDate - 09/27/2019
dvi: Version - 9.24.2.601
dvi: {Build Driver List - exit(0x)} 11:26:36.447
dvi: {DIF_SELECTBESTCOMPATDRV} 11:26:36.447
dvi: Using exported function 'NetClassInstaller' in module
'C:\Windows\system32\NetCfgx.dll'.
dvi: Class installer == NetCfgx.dll,NetClassInstaller
dvi: Using exported function 'NciDeviceInstall' in module
'C:\Windows\system32\nci.dll'.
dvi: CoInstaller 1 == nci.dll,NciDeviceInstall
dvi: Using exported function 'WlanDeviceClassCoInstaller' in module
'C:\Windows\system32\wlaninst.dll'.
dvi: CoInstaller 2 == wlaninst.dll,WlanDeviceClassCoInstaller
dvi: Using exported function 'WwanDeviceClassCoInstaller' in module
'C:\Windows\system32\wwaninst.dll'.
dvi: CoInstaller 3 == wwaninst.dll,WwanDeviceClassCoInstaller
dvi: CoInstaller 1: Enter 11:26:36.494
dvi: CoInstaller 1: Exit
dvi: CoInstaller 2: Enter 11:26:36.494
dvi: CoInstaller 2: Exit
dvi: CoInstaller 3: Enter 11:26:36.494
dvi: CoInstaller 3: Exit
dvi: Class installer: Enter 11:26:36.494
dvi: Class installer: Exit
dvi: Default installer: Enter 11:26:36.494
dvi: {Select Best Driver}
dvi:Selected driver installs from section [tap0901.ndi] in
'c:\program files\tap-windows\driver\oemvista.inf'.
dvi:Class GUID of device remains:
{4d36e972-e325-11ce-bfc1-08002be10318}.
dvi:Set selected driver complete.
dvi:Selected:
dvi: Description - [TAP-Windows Adapter V9]
dvi: InfFile - [c:\program
files\tap-windows\driver\oemvista.inf]
dvi: Section - [tap0901.ndi]
dvi: Signer - [OpenVPN Inc.]
dvi: Rank- [0x00ff]
dvi: {Select Best Driver - exit(0x)}
dvi: Default installer: Exit
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x)} 11:26:36.510
Re: [Openvpn-devel] [PATCH applied] Re: maddr: export VLAN ID from client context to maddr object
Hi, On Wed, Nov 06, 2019 at 10:11:58PM +0100, Gert Doering wrote: > As a side note: it seems that whoever did the IPv6 payload patches was > a bit sloppy (it was me, so I am allowed to say that). MAC learning is > only done on IPv4 and ARP packets, but not on IPv6 packets - so I expect > "ipv6 only mode on tap" to be a bit wacky... this needs re-testing > before we can declare "ipv6-only works reliably". I was wrong here. This part is only for the extraction of the "inner" addresses in an tap/ethernet packet, which are then subsequently used for ENABLE_PF filtering. Since *that* only has IPv4 (because nobody reviewed and ACKed Antonio's "make PF support IPv6" patches yet) it makes sense that the code only extract IPv4 addresses. Now, I see a slight merge conflict with the PF/IPv6 patch set... :-) 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 g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: maddr: export VLAN ID from client context to maddr object
Acked-by: Gert Doering Stared at the code, ran client side tests, full set of server side tests, and compiled (+client tested) on FreeBSD 7.4 to give the "anonymous union explosion" bits a good checking :-) (it does not explode anymore, thanks for fixing that). Similar to 2/9, this patch does not actually change behaviour yet - it adds the 2-byte vid to the hashed ethernet address for per-client learning, but as all callers set it to "0", there is no "vlan separation" effect yet (I know it's coming in a future patch, just pointing out why this patch does not change visible behaviour yet). It shows up in the "MULTI: Learn" lines already, though Nov 6 22:04:51 gentoo tap-udp-p2mp[11510]: freebsd-11-amd64/2001:608:0:814::f000:16 MULTI: Learn: 00:bd:b5:63:b5:04@0 -> freebsd-11-amd64/2001:608:0:814::f000:16 .. the "@0" bit after the MAC address is the PVID. As a side note: it seems that whoever did the IPv6 payload patches was a bit sloppy (it was me, so I am allowed to say that). MAC learning is only done on IPv4 and ARP packets, but not on IPv6 packets - so I expect "ipv6 only mode on tap" to be a bit wacky... this needs re-testing before we can declare "ipv6-only works reliably". Your patch has been applied to the master branch. commit a2b7230712dbc8cfab85d5bd59605f58fc5fe5f8 Author: Antonio Quartulli Date: Wed Oct 9 16:34:16 2019 +0200 maddr: export VLAN ID from client context to maddr object Signed-off-by: Fabian Knittel Signed-off-by: Antonio Quartulli Acked-by: Gert Doering Message-Id: <20191009143422.9419-...@unstable.cc> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18917.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: VLAN: add basic VLAN tagging support
Acked-by: Gert Doering Stared at the code (twice now), run t_client and t_server tests. This patch does not really *do* much yet, but it lays the groundwork for future work - the "broadcast only to clients in the same vlan" part is there, but it's always called with "0" (= all clients). As far as I can see, the only notable behavioural change we have so far is "if a client is assigned a pvid (!= the global pvid), it will not be able to communicate with the TAP interface" (check in vlan.c, vlan_process_outgoing_tun()), but client-to-client is still allowed, and there is no per-vlan MAC learning yet either. (Most notably, it only adds options and code relevant for TAP mode) Your patch has been applied to the master branch. commit 99f28081477ca325a14b13c38abec2c9b619eb01 Author: Antonio Quartulli Date: Wed Oct 9 16:34:15 2019 +0200 VLAN: add basic VLAN tagging support Signed-off-by: Fabian Knittel Signed-off-by: Antonio Quartulli Acked-by: Gert Doering Message-Id: <20191009143422.9419-...@unstable.cc> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18924.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Fix broken fragmentation logic when using NCP
Acked-by: Gert Doering Thanks for clarifying what the actual problem is, so we have it nicely in the logs. I have diff'ed this patch vs. d22ba6b2c551f, and the only difference is related to "use_iv" which got kicked out from master. So I'm mostly relying on the ACks from Arne and Steffan and not doing any review myself :-) - I have done a full client test, of course. Your patch has been applied to the release/2.4 branch. commit 3bd91cd0e68762b861c57cf37f144d8a11704e9d Author: Lev Stipakov Date: Wed Oct 30 14:44:59 2019 +0200 Fix broken fragmentation logic when using NCP Signed-off-by: Lev Stipakov Acked-by: Gert Doering Message-Id: <1572439499-16276-1-git-send-email-lstipa...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18975.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN 2.4.8 released
Hi, Il Mercoledì 6 novembre 2019, d tbsky scrive: > after reading the thread, I think now it's safe to upgrae my windows 7 > from openvpn 2.4.7 to 2.4.8. so I download the installer and click > it. > > the installer complains about can not install tap drivers and I click > ok to let it go. when I try to connect, openvpn said the tap driver > is in use and failed. > I reboot and reinstall but still can not see tap device in my network. > > finally I uninstall tap and openvpn then install again, this time > everything is ok, I am lucky. > so openvpn-gui 2.4.8 upgrade is not as smooth as previous versions. It would be interesting too what error message there is in setupapi.dev.log: https://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers It seems to me like some changes that were made since the previous release cause upgrade issues. Samuli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] tun/iproute2: support 31-bit ipv4 prefix (RFC 3021)
Hi,
On Mon, Nov 04, 2019 at 05:10:12AM +0800, Tom Yan wrote:
> So in master, when net_addr_v4_add is called in tun.c, which
> net_addr_v4_add (networking_iproute2.c or networking_sitnl.c) is
> actually used depends on how openvpn is built, right?
Right. It's either "default options" (-> sitnl.c) or "--with-iproute2"
(->networking_iproute2.c).
2.4 has "ifconfig or iproute2"
2.5 has "direct interface to netlink" (sitnl) or "iproute2"
> I think the `if (broadcast)` condition in the one of
> networking_sitnl.c needs to be changed to `if (broadcast && prefixlen
> < 31)` as well.
I think this is more something the caller needs to decide "do I want to
set a broadcast address or not" (so, if /31, set broadcast = NULL).
OTOH, I'm still waiting for someone to tell me why we'd want to set
a broadcast address in the first place :-) - Antonio, you know the
kernel side better. Why would anyone explicitly configure the standard
broadcast address ("all-ones in the host part of the relevant subnet")?
> Also it seems that net_addr_v4_add is called wrongly
> in tun.c with `>remote_netmask` instead of `>broadcast` as the
> last argument.
I tend to agree with you here.
Antonio, yours :-) (though I ACKed it) - tun.c, line 1092.
We do mix up "remote" and "netmask" in the shared "remote_netmask"
variable, but "broadcast" is independent of that... and OpenVPN
actually tells us so, in the "topology subnet" case...
net_addr_v4_add: 10.194.6.2/24 brd 255.255.255.0 dev tun1
Linux seems to accept this, but it has no further consequences ("all
my tests pass")...
$ ip addr show dev tun1
520: tun1: mtu 1500 qdisc pfifo_fast
state UNKNOWN group default qlen 100
link/none
inet 10.194.6.2/24 brd 255.255.255.0 scope global tun1
valid_lft forever preferred_lft forever
... but it's still not correct.
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 g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
