The problem is easily seen most times when a DHCP range is canceled.
The cancel completely fails to work, and refuses to cancel until
correct values are put in start and end. (However, pressing the ESC
key sometimes helped.)
The problem is seen in the first puzzle if you ping
pc0, and then edit the 0.0.0.0 gateway. It auto-fills in
the last-used pc0 IP address, and canceling saves that change
instead of leaving the gateway at 0.0.0.0.
lastIP nicely saves some typing (although it has also confused
my student quite a bit I think), but since it updates WhatToEdit,
that becomes the "saved" value even during a cancel.
Instead, save the original value as a copy, and set back to
the original value when cancellng.
Perhaps it would be worth creating a reparse( NB_IPAddress)
function, but this was easy to just hack together.
Tested by pinging pc0, then editing the gateway and cancellng,
editing the IP address and canceling.
Next: don't add a canceled route
This was especially bad when lastIP filled in default values,
so this patch pretty much depends on the patch that cancels
the auto-filled lastIP.
This didn't cause a problem - it just cluttered up the routing
table with duplicate, undeletable routes.
ping source is firewall ? set sourceIP to vpn IP address
The problem can be seen easily in Puzzle 2, VPN Demo.
From firewall2, ping firewall0. The ping request tunnels
to firewall0 with a source address of 0.0.0.0, and so
the reply returns untunneled and drops at the default gateway.
This patch probably needs to be tweaked a bit in case it
covers too many situations, but in general something like
this is needed.
