• anonym's avatar
    Completely rewrite the firewall leak detector. · c2a2465c
    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
    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