-
anonym authored
The old design was very inflexible, which over time lead to the implementation growing messy as different checks were added. The issue was that it had to hard-code the particular checks we wanted, and did not allow the user to formulate an expression for which packets are considered leaks or not. So, let's instead provide an assertion-like function to which the user passes a block describing how we want all our packets to look. Furthermore, now all firewall leak tests should be ok with the simulated Tor network provided by Chutney. Since all Tor nodes (incl. bridges) run from the same host (and IP address) we also include the server port when verifying that no unexpected hosts were contacted. Note that in some cases we've lost a bit of information and precision, e.g. among the anti-tests we no longer exactly match the protocol that was leaked, but that wasn't very valuable to begin with, and instead we test *exactly* the code that these are anti tests for -- a true anti test, indeed! Also, the 'no traffic has flowed to the LAN' (now renamed) had a serious bug which was fixed in passing -- the `@lan_host` variable was not set, so it is `nil`, which could never be among the IPv4 TCP leaks, so that step always succeeded! :S
c2a2465c