Wintun doesn't have its own I/O device. Rather, it taps on existing
Windows-provided NDIS device. Sending TAP-Windows6 IOCTL requests to it
is risky, as TAP-Windows6 is using one of the well-known device types
(FILE_DEVICE_UNKNOWN) with function IDs as 1, 2, 3 etc. raising a chance
of collision as NDIS might react to one of these IOCTLs.
Signed-off-by: Simon Rozman <simon@rozman.si>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <
20200108115224.38-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19309.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
}
#elif defined(_WIN32)
/* get possible driver error from TAP-Windows driver */
- extended_msg = tap_win_getinfo(tt, &gc);
+ if (tuntap_defined(tt))
+ {
+ extended_msg = tap_win_getinfo(tt, &gc);
+ }
#endif
if (!ignore_sys_error(my_errno))
{
#ifdef _WIN32
if (tuntap_defined(c->c1.tuntap))
{
- status_printf(so, "TAP-WIN32 driver status,\"%s\"",
- tap_win_getinfo(c->c1.tuntap, &gc));
+ const char *extended_msg = tap_win_getinfo(c->c1.tuntap, &gc);
+ if (extended_msg)
+ {
+ status_printf(so, "TAP-WIN32 driver status,\"%s\"", extended_msg);
+ }
}
#endif
const char *
tap_win_getinfo(const struct tuntap *tt, struct gc_arena *gc)
{
- if (tt && tt->hand != NULL)
+ if (!tt->wintun)
{
struct buffer out = alloc_buf_gc(256, gc);
DWORD len;
void
tun_show_debug(struct tuntap *tt)
{
- if (tt && tt->hand != NULL)
+ if (!tt->wintun)
{
struct buffer out = alloc_buf(1024);
DWORD len;