|
|
> The DHCPREQUEST and DHCPACK is probably just Windows making sure that after > wakeup, the adapter properties are still current. The dhcpd in the TAP-Win32 > driver will tell it "yes, the properties haven't changed" via the ACK. > > What does "route print" say? Maybe there is a way to tweak the metric so the > TAP interface keeps precedence. Well, it appears I'm wrong -- while `route print' shows the old gw listed first (probably in numeric order or something), its metric is higher than the tun gw, which would indicate the tun gw still has "precedence". This is assuming that a higher metric means higher "cost". Below is a snippet of the routing table before and after the machine has resumed from a standby: BEFORE STANDBY: c:\>route print 0* ...cut... =========================================================================== Active Routes: Network Dest Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.200.1 192.168.200.2 1 Default Gateway: 192.168.200.1 =========================================================================== Persistent Routes: None AFTER STANDBY: c:\>route print 0* ...cut... =========================================================================== Active Routes: Network Dest Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.1.1.1 10.1.1.10 30 0.0.0.0 0.0.0.0 192.168.200.1 192.168.200.2 1 Default Gateway: 192.168.200.1 =========================================================================== Persistent Routes: None Indeed, the tun route *still* has precedence. Therefore the addition of the old gw would appear to be harmless, as it should *never* get chosen. Should. I'll run some more tests to confirm. I previously thought the old route might be causing problems... but perhaps it is something else. Thanks. -Adam |