WellDone ought to default to "false" so that canceling the
form does not return a true.
However, that then means that the validating (particularly for DHCP)
needs to be handled differently. Otherwise validation would ONLY
occur when you press OK. (Not a terrible thing, but also not ideal.)
In any case, this is a solution I found on the internet. It seems
to work nicely. Validating still runs unless the form is closing
(via ESC, Cancel, or X), including when moving from textbox to
textbox, or tabbing to OK.
I think this also solves a lingering problem where DHCP couldn't
X out without attempting to validate. So it feels like an all-around winner.
Step to reproduce: Level0 ping test
1.) on net_switch0, try to ping pc0.
-tab through and notice that pc0 resolves to 192.168.1.2 on OK button.
2.) close with form window using X
-notice that the ping happens anyway. Same is true for arp and traceroute.
If a device does a traceroute to the opposite side of a router,
the traceroute request will continue on to the next gateway
until it dies from not being able to return on the same NIC.
Instead, respond to traceroute requests from the "pinged"
ip address (so that the originator stops requesting more
tracert packets) instead of the closest address to the
originator.
Scenario: Level 3 It is dead, Jim
1.) from PC1, traceroute to the far side of router2 (192.168.3.2).
Notice that the tracert continues on two times to router0 before
dying.
Things like switches could not be tracert'd.
Scenario: Level 3 It is dead, Jim.
1.) from PC2, do a tracert to net_switch0.
Notice that there is no response.
pinging 0.0.0.0 should not go anywhere, but previously
it could be routed anywhere by default gateways etc.
Scenario: Level 3 It's dead Jim
1.) set the gateway for PC2 to router2
2.) ping net_switch1
The ping travels halfway around the network before it is dropped.
Even worse is L4 Who done it, where
originally the puzzle could be solved by
just pinging 0.0.0.0 enough times.
When a server or firewall changes the IP address of a network
card, any DHCP ranges associated with that old number were
zeroed out.
Invalidating the range COULD be a nice feature in case the
new IP address falls within the DHCP range - thus preventing
conflicting IP addresses. So just to be nice I did allow the
range to invalidate in that situation. However, in real life
it wouldn't be so nice, and so perhaps it would actually be
better to keep the existing rules intact even if it would
cause a problem.
Scenario: Level 2 Firewall Test
-change firewall eth0 to 192.168.1.10 and eth1 to 192.168.2.20
-click OK
-edit firewall again and look at the DHCP rules
-notice that 192.168.1 has all zeros.
-same thing with 192.168.2
-after the fix, the 192.168.2 rules are retained since
2.20 doesn't conflict with the range, but 1.10 does
conflict, so that rule was invalidated.
If the user types in a name in the IP Address Entry form,
also replace the subnet mask.
This is particularly useful for pinging, since ping doesn't
allow access to the subnet mask field, and if an inappropriate
mask is autoIP-entered, then the results might be unexpected.
Exception for DHCP ranges: Actually, it shouldn't be necessary
(since the IP address field is disabled for DHCP), but just
for completeness, I ensure that the second field is not altered
for DHCP range entries.
Scenario: Level4, Small Subnets
1.) fix router2, so the subnet mask is /30
2.) from pc1, ping pc2 (which is address 192.168.1.3)
-lastIP sets subnet mask to 255.255.255.252
-that makes .3 the broadcast address
-fix result: lastIP mask is replaced by pc2's real mask.
Ultimately, the problem stemmed from a ping to an address
with the wrong subnet mask (auto-filled subnet) which turned
the address (which should have been routed) into a local broadcast.
Only the global broadcast, or a local broadcast should be accepted,
not a broadcast that should be routed.
This can be seen in Level 4, Small Subnets puzzle.
1.) fix router2 to be /31
2.) from pc1, ping pc2 (which turns into 192.168.1.3)
-autoIP filled in a subnet mask of 255.255.255.252
-therefore 1.3 is considered the broadcast IP.
-result: a local broadcast on the 192.168.2 network.
3.) from pc1, ping 192.168.1.1 or 192.168.1.4 works fine.
4.) edit firewall1, edit route to 192.168.1.1
-make no changes, just hit OK
5.) again from pc1 ping pc2
-now autoIP fills in subnet mask 255.255.255.0
-result: it works
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.
Tim Young