[Vpn-help] Iked.exe dies

[Peter Eisch]

On 10/24/07 12:10 AM, "Matthew Grooms" <mgrooms at shrew.net> wrote:

> Thanks again for the bug report. I'm glad you caught this as I was just
> writing the 2.0.2 release announcement. This build should set you
> straight :)
> 
> http://www.shrew.net/vpn/download.php?name=vpn-client&vers=2.0.2-release-x86
> 

This is good!  It popped right up and worked as you'd expect.

I had errantly launched netcfg.exe when I was clicking around.  This
unfortunately did something that made the uninstall of 2.0.0 (which didn't
have the 2.0.1 problem) hang.  I killed the processes and then reinstalled.
During the install it seemed to hang at netcfg and I ended up having to
restart the system (via poweroff).  I restarted and was greeted with the
need to [re]validate XP.  I didn't at that point because there wasn't any
networking.  I figured out that it was probably my errant clicking that
caused the problem when there were two unnamed Net devices which were then
trying to auto-install.  I deleted the devices from the device manager,
rebooted (again by poweroff), uninstalled and rebooted (normally this time).
When it came back up I installed the 2.0.2 flawlessly and all is good.

I don't know if there's a bug in there -- probably just a NB.

Also, we consistently get a behavior where the VPN needs to be up for 9-11
minutes before it starts "working."  The issue isn't in transport -- that is
working properly.  The problem is that windows seems to cache public DNS
responses for about that long and it doesn't retry over the VPN until that
cache expires.

For example the user has Outlook running with no/vpn.  They then connect the
VPN and general Internet browsing mostly works (caching behavior doesn't
seem to happen) but Outlook literally sits at "Trying to connect..." [to
exchange] through this duration.  Even if it's quit before the VPN is
launched.  This leads me to think that there might be some sort of WINS
cache or something that needs to get poked when connected and disconnected.
What too is odd is that from a cmd prompt the public addresses are used if
you try to ping these domain systems.  Again, non-domain systems tend to
respond properly.

On OS X the trick is to signal USR2 to lookupd (well, it was through 10.3,
I'm just new to 10.4) to drop its cache.  Is there something similar that
can be done on windows?

Thanks Matt!

peter