| Age | Commit message (Collapse) | Author |
|---|
|
load in Windows 2008 Server and Windows Vista. Still issues with those platforms, but driver loads -- and shouldn't hurt newer versions (will test).
|
|
Shouldn't be needed but seems to help on Windows 8.
|
|
including automatic driver update from NDIS5 to NDIS6. Also a bit more robust on creating new ports, just in case.
|
|
reassigned on device "power cycle."
|
|
|
|
setupapi and using these functions directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
restart problem. Installer probably should NOT mess with the running service, since Linux servers are likely to be production.
|
|
|
|
|
|
|
|
|
|
|
|
problem. Have to test a bit more.
|
|
and clean up service start/stop in installer.
|
|
|
|
configure firewall rules (because we can now).
|
|
|
|
(clean). (And Windows 10, and Windows Server, and ...)
|
|
(1) Yes, you *can* create a mixed 32/64 bit Windows MSI installer that installs drivers. All you have to do is... umm... create individual sub-MSI files for each driver (one for 32, one for 64) and then package those in the main MSI files as "chained" MSI installers. Each of these must only be considered a prerequisite on 32 or 64 bit machines, respectively.
(2) Upgrade Advanced Installer version, add rules to uninstall NDIS6 tap device on uninstall.
(3) Fix IE issue in UI code.
|
|
|
|
bootstrapping .app and installer script.
|
|
|
|
|
|
This version is mostly a bug fix release. It fixes a bug that could cause
the service to crash on Windows while running the GUI application. It also
contains a number of fixes to the Linux installer and Linux support for
systemd-based init systems.
It also includes a minor tweak to the multicast algorithm. Version 1.0.0
sent multicasts in a deterministic order, while this version randomizes
the order. The vast majority of users will notice nothing, but this may result
in superior coverage for service announcements on very large networks. It's
a hard variation to test, so we're releasing like this to gather information
from users about the effect. Nothing will change on small networks, and
ordinary multicast functions like ARP and NDP should be unaffected.
The next version will likely focus on additional improvements to Microsoft
Windows support, since there are several known Windows issues in need of
attention. We're working on an NDIS6-based Tap driver that should address
the driver issues experienced by a small number of Windows 7 users.
|
|
outside normal RPM channels.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The primary focus of this version is better integration with the
Microsoft Windows operating system.
Virtual networks should now be detected as "real" networks. For
each network, a message box should pop up the first time the network
is detected and classified allowing the user to choose its services
and security designation. On Windows 7 this is "work," "home," or
"public." On Windows 8 it's a simple choice of whether or not to
enable file and printer sharing and other services.
Several bugs have been fixed. Among these are a Windows threading
issue, several minor threading deadlock issues that could manifest
if rapidly adding and removing networks, and a command line interface
issue. The network list now shows the network MAC address as well,
a UI oversight in previous versions. A vectorized SSE implementation
of Salsa20 is now included for improved encrypt/decrypt performance.
The sending of low-TTL "firewall opener" packets has been disabled
in this version, since they may not be necessary and may harm NAT
traversal in some configurations. We will measure the effectiveness
of NAT traversal and see if this change improves performance in the
field.
Finally, this version obsoletes both the Tokyo and Sydney supernodes
in favor of a single larger supernode in Singapore. This decision was
made on the basis of bandwidth costs-- both Tokyo and Sydney are
significantly more expensive. We'd like to keep the basic service free,
so keeping bandwidth costs for relaying low is important. Since NAT
traversal works well and is constantly being improved, most users will
not see a speed decrease from this. Some Chinese users may see
improved performance since Singapore may be closer than Tokyo to many
Chinese cities.
The next major releases will focus on better Macintosh platform integration,
further improvements to NAT traversal, and UI improvements.
|
|
network now doesn't leave networks in limbo.
|
