1. 19 Mar, 2017 1 commit
    • anonym's avatar
      Test suite: try possible fix for #11508. · 112b34da
      anonym authored
      Yup, it seems that all along I've just missed that we could have
      IPv6Packet:s in `ip_packet`, and their source is accessed by
      `.ipv6_saddr`, not `ip_saddr` (that's for IPv4Packet). So, let's just
      try and see which one of the two each `ip_packet` has, because one of
      them must be there!
      
      Also, given that UDPPacket can be either IPv4 or IPv6 it seems safest
      to try to parse each packet as IPv6Packet first -- that way we keep
      looking at transport layer protocols for IPv4 only, and treat
      everything IPv6 as the same, which makes sense, since we should block
      all IPv6, so everything should be treated the same at all times.
      
      Refs: #11508
      112b34da
  2. 18 Mar, 2017 1 commit
    • anonym's avatar
      Test suite: refine debug info collection of #11508. · fdd50f83
      anonym authored
      I have seen yet another:
      
          NoMethodError: undefined method `ip_saddr' for nil:NilClass
      
      So we now know that `ip_packet` is not `nil`, it just doesn't have the
      `ip_saddr` method (and probably not the `ip_daddr` one either) some
      how (feels strange for an IP packet to not have a source or
      destination address...).
      
      Refs: #11508
      fdd50f83
  3. 13 Mar, 2017 1 commit
  4. 02 Feb, 2017 1 commit
  5. 21 Jan, 2017 2 commits
  6. 01 Nov, 2016 1 commit
  7. 11 May, 2016 3 commits
  8. 02 May, 2016 1 commit
  9. 20 Apr, 2016 1 commit
    • 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
      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
  10. 19 Jan, 2016 2 commits
  11. 13 Oct, 2015 1 commit
  12. 06 Oct, 2015 4 commits
  13. 04 Oct, 2015 1 commit
  14. 10 Apr, 2015 1 commit
  15. 04 Mar, 2015 1 commit
  16. 19 Feb, 2015 3 commits
  17. 18 Feb, 2015 2 commits
  18. 03 Feb, 2015 1 commit
    • Tails developers's avatar
      Move misc code into FirewallLeakCheck. · 9704789f
      Tails developers authored
      This is where it belongs, and soon we'll need to use the same code in
      a scenario hook, and calling a step in such a way makes me
      uncomfortable.
      
      (FWIW, this is a remnant from the good ol' unmerged
      test/firewall-check-tag branch.)
      9704789f
  19. 19 Jan, 2015 1 commit
  20. 02 Apr, 2013 4 commits
  21. 31 Mar, 2013 1 commit
  22. 30 Mar, 2013 1 commit
  23. 29 Mar, 2013 1 commit
    • Tails developers's avatar
      Don't hide problems. · a97c24a8
      Tails developers authored
      ... especially when the problem is supposed to be fixed already:
      we do want to make sure it is, and that no regression occurs.
      a97c24a8
  24. 27 Mar, 2013 1 commit
    • Tails developers's avatar
      Reorganise features/, unifying both test suites. · 375216ce
      Tails developers authored
      Now all .feature:s reside directly in the root of features/, and they
      are differentiated with tags: source tests are tagged '@source' and
      product (i.e. Tails ISO image) tests are tagged '@product'. These tags
      then set up the appropriate environment on a feature-by-feature basis.
      375216ce
  25. 25 Jan, 2013 1 commit
  26. 31 Oct, 2012 2 commits